你有没有在 VS Code 的聊天窗口（Chat）里试图按Ctrl+F找东西，然后发现——啥也没发生？
对，一直以来，VS Code 的聊天窗口不支持原生的查找功能。你想在对话记录里找某个关键词，要么靠肉眼扫描，要么只能把内容复制到编辑器里再搜。反而zed在很早就支持这功能了。
这个问题终于在新版本中被解决了。但真正让我觉得有意思的，不是“他们加了个查找框”，而是他们为了加这个查找框，到底踩了多少坑。
看起来简单，做起来一点都不简单
vscode干的事情，表面上看就是给聊天窗口加了个Ctrl+F。但仔细看代码改动，你会发现这玩意儿比想象中复杂得多。
聊天窗口不是普通文本，它是一堆混合内容的组合体：
- Markdown 文本
- 代码块
- 链接
- 引用
- 折叠的思考过程（Reasoning）
- 流式输出的内容
如果直接对 DOM 做全文搜索，你可能会搜到代码块里的内容，但高亮又没法正确标记位置。或者搜到折叠内容里的文字，但用户根本看不到那段内容。又或者正则表达式太复杂，直接卡死渲染进程。
几个让人头大的问题
问题一：折叠内容怎么办？
聊天窗口里有很多折叠的思考过程（Reasoning），它们默认是折叠的。如果你能搜到折叠内容里的文字，但用户看不到，那这个查找就没意义。所以实现里把 Reasoning 内容排除在了搜索范围之外——虽然理论上它能搜到，但无法定位，干脆不搜。
问题二：代码块怎么处理？
代码块在聊天窗口里是用 Monaco 编辑器渲染的，不是普通 DOM。如果直接把代码块里的内容当作纯文本索引，高亮逻辑就会出问题——因为它要同时处理 DOM 高亮和编辑器内高亮。实现里专门处理了这种情况，把代码块里的匹配项单独标记，用编辑器装饰（decoration）而不是 DOM 高亮来显示。
问题三：性能怎么保证？
聊天窗口可能有上千行内容，如果每次搜索都要重新扫描整个 DOM，会很卡。实现里用了分段索引（transcript indexing），把内容分块，只搜索可见部分和必要的折叠部分。同时为了防止卡死，还对匹配数量做了上限控制（MAX_FIND_MATCHES），避免极端情况下的性能问题。
虽然vscode面临的问题很多，但是使用却很简单，方式和vscode之前的全局搜索几乎一模一样。
最后
很多人可能觉得“加个 Ctrl+F 有什么好说的”，但正是这种看起来“简单”的功能，往往是最能体现工程质量的。
这个 新特性涵盖的场景包括：
- 普通文本搜索
- 代码块内的搜索
- 折叠内容的处理
- 流式输出时的搜索
- 正则表达式搜索
- 高亮定位的准确性
它不只是把浏览器原生 Ctrl+F 套了一层壳，而是为聊天窗口这个特殊环境重新实现了一套查找系统。
现在你在聊天窗口、聊天编辑器（Chat Editor）、甚至是 Agent 窗口里，都可以用Ctrl+F来搜索对话记录了。这个功能现在已经合入主分支，你可以在下一个 VS Code 版本（或者 Insiders 版本）里体验它了。
以后在聊天窗口里找东西，再也不用复制到编辑器里搜了——虽然你可能花了三秒钟才意识到这个变化。但下一秒，你会发现它已经在悄悄工作了。
