E4.18.2find-in-page vs virtualized rows设计研究
页面内查找在虚拟滚动下可能失效
别名: 虚拟列表查找 · 查找找不到 · 未渲染行 · virtual find
概念解释
系统的「页内查找」在已经画出来的文本上匹配。虚拟列表把窗口外的行卸掉，那些行的文字不在文档里，查找就会报没有，即使数据里明明有。这是窗口与查找的裂缝（find versus windowed rows）：用户以为在搜整份列表，系统只在搜当前这一屏。它和折叠块藏内容不同——折叠至少还把节点留在树上；虚拟化是节点根本没被创建。
机制
查找的实现默认「可见页面的文本 ≈ 文档树的文本」。虚拟化故意打破这个近似：为了性能，树只覆盖窗口。匹配因此被窗口裁切，远端命中不会进入计数，也不会被滚到。应用若提供自己的搜索框却仍只扫可见节点，会复制同一裂缝，只是换了入口。要补上，查找必须走数据层：在完整数组里匹配，再把窗口跳到那一行并创建节点，高亮才有附着点。不跳窗口只报「找到了」，用户仍然看不见。计数也必须以数据层为准，否则「1 / 1」其实是「这一屏的 1 / 1」。
怎么研究
在长虚拟列表里埋一个只出现在远端行的词，用系统查找和应用内查找分别去定位。自变量：查找是否查询数据层、命中后是否跳窗口。因变量：报告找到、实际看见高亮、错误的「无结果」。系统查找在未打补丁的虚拟列表上应系统性漏报远端词。
边界
应用禁止系统查找、只提供自己的、且明确写着搜全部数据，裂缝可以补上。打印和导出若走数据层，不受窗口限制，但那不是查找。辅助技术的「在页面中查找」同样只看见树里的节点，需要同一条数据层通道，并在跳转后把焦点放到新创建的行上。短窗口缓冲不会拯救查找——缓冲仍远小于全集。
怎么落地
- 为虚拟列表提供走数据层的查找，命中后滚动窗口并渲染该行再高亮。
- 不要让系统查找在未补丁的虚拟列表上充当「搜全部」；做不到就在无结果时说明只搜了可见行。
- 命中计数按全集，不要按窗口。
- 验证：搜一个只在第 N 屏出现的词。必须看见该行高亮。只报找到或报无结果，裂缝就还在。