懒加载内容需可被页面内搜索发现
别名: 页内搜索与懒加载 · find in page · 未加载不可搜
概念解释
页面内搜索（find in page、⌘F、控件自带的筛选）假定「页上有的字都能被找到」。懒加载若把未进视口的文本、列表行、折叠面板从 DOM 里拿掉，或根本还没取回来，搜索就会报「没有」，而内容其实在下面等着被滚到才存在。懒加载降低了首屏成本，不能顺手把可发现性（findability）也降低：还没画出来的内容，对搜索仍然必须是可命中的，或在命中时被立即取来并滚到。
机制
搜索走的是已经在文档里的字符串，不是视觉上的可见性。懒加载常见实现却把「未接近视口」做成「节点不存在」：虚拟列表只挂几行，其余只是高度记账；折叠段的正文要等打开才插入；图片的 alt 还在服务器上。用户按词去找，引擎在现有节点里扫一遍，零命中，人的模型是「页里没有这个词」。模型错了，因为词在尚未物化的那一段里。可发现性要求物化与搜索共用一份索引：要么未画的文本仍以可搜形式存在（隐藏但不删除、有一份文本索引），要么搜索命中未加载段时，先加载再定位，而不是返回没有。
虚拟化特别容易踩这条。它为了滚动手感只渲染窗口，窗口外的行在无障碍树和找词功能里都会消失。滚动用户能「感觉」内容还在，搜索用户没有这条感觉，只有一次假阴性。
边界
图片懒加载通常不把正文拿走，页内搜文字不受影响；但若关键信息只写在图里、又没有可搜的替代文本，搜不到是内容形态问题，不是触发线问题。服务端分页、无限列表里「还没请求过的页」确实不在本页，搜本页搜不到是对的，应让人知道范围是「已加载的这些」并提供全库搜索，而不是假装整库都在 DOM 里。加密或权限未解锁的段本就不可读，搜索也不该提前揭开。浏览器原生找词对跨文档、canvas、Shadow DOM 的能力本身有限，产品内的查找要自己补，不能假设原生 ⌘F 能穿透虚拟列表。
怎么落地
- 虚拟列表和懒折叠为页内查找保留一份可搜文本（隐藏节点或独立索引），命中后滚到该处并加载真实内容。
- 产品自己的搜索框若只扫已渲染节点，等于把懒加载变成静默丢词；要扫逻辑文档。
- 无限滚动要标明「仅搜索已加载部分」，并给出搜全部的入口，避免假阴性被当成没有。
- 验证：滚到中部才加载的那段里放一个独特词，回到顶部 ⌘F 或用页内查找。找不到，或找到了却不能定位到尚未渲染的行，可发现性就被懒加载吃掉了。