从一万条消息里，找出那一条

一万条消息摆在面前，你只想取最后一条。每次从头找，还是提前建个索引？先亲手改一次查找目标，看工作量怎样变化，再把这份直觉带到 React 的 key、缓存的内存开销和模型的 KV Cache。

先回答三个问题

问题	阅读入口	可以动手观察什么
为什么需要 key 和 Map	key 与索引	数组查找与预先建立索引的成本
已经缓存了，为什么仍然慢或占内存	缓存的成本	引用、保留的数据、命中率和失效范围
模型为什么要保存那么多 KV	为什么 KV 会这么大	从一个向量推到整段上下文的容量

打开数组与 Map 浏览器实验，先猜一下：查第一项和最后一项，哪条路径的工作量会变？运行后对照自己的预测，再回到第一篇，看看额外索引换来了什么。

这一轮想带走的本领：看到一个“查得快”的结果时，也会顺手问一句，索引是什么时候建的、占了多少空间。

分清我们在优化什么

“更快”可以来自减少查找、减少重复计算、减少数据搬运，或让主线程更早处理用户输入。这些是不同的工作，适合的工具也不同。

想减少的工作	熟悉的前端工具	进一步通向哪里
反复从头查找同一个对象	Map、按 ID 建立索引	数据身份与缓存键
对相同输入重复计算	useMemo、派生结果缓存	前缀复用与 KV Cache
一直保存不再需要的数据	作用域、删除、容量限制	模型缓存的生命周期
阻塞界面事件处理	分批处理、Web Worker	Wasm 与推理任务调度
大块数值计算和运行既有库	TypedArray、WebAssembly	浏览器端模型运行时

先确定被减少的工作，再比较整体耗时与空间；一次函数调用少了，背后的数据准备也可能变多。

接下来读：key、Object、Map 与 WeakMap。