浏览器端推理插件不能只看演示
浏览器端推理插件很容易做出吸引人的演示：选一段干净短文本，点击按钮，几秒后得到摘要、翻译或分类结果。但真实网页不是准备好的测试样本。页面里有导航、广告、隐藏节点、代码片段和动态加载内容，还可能混着多种语言。插件如果只在理想输入上表现正常，安装到日常浏览环境后，很快就会暴露问题。
因此，验证的起点不是多截几张成功页面，而是明确插件究竟读取什么。是用户选中的文本、当前可见区域，还是整个 DOM？不同选择涉及不同的输入噪声、性能开销和权限范围。若只需要处理选中文本，就不该默认读取整页；若必须解析页面结构，也应排除脚本、样式、隐藏节点和编辑框里的内容。
把真实页面里的麻烦带进测试
我会准备一份手工案例清单，覆盖空标签、超长段落、混合语言、表格、代码块、图片替代文本、动态更新和离线状态。案例不必来自真实用户网页，可以用自行构造的脱敏页面复现结构。这样既能稳定回放，也不会把浏览记录或页面正文带进测试仓库。
每个案例都要写出预期行为。页面没有可用文本时，是静默结束还是告诉用户重新选择？输入太长时，是分段、截断还是拒绝？语言无法识别时，是否保留原文？只有预期写清楚，团队才能区分“模型效果一般”和“插件行为错误”。
离线处理也不能只靠一个网络状态判断。navigator.onLine只能提供当前连接提示，无法保证某个模型资源或远端服务一定可用。下面的判断可以作为入口，但后续仍需捕获模型加载、缓存读取和推理过程中的失败。
if (!navigator.onLine) return fallback(input);备用路径也要说清能力差异。如果离线模式只能完成简单规则匹配，就不要把它包装成与在线模型等价的结果。用户需要知道当前使用了哪种处理方式，输出是否被截断，以及重新联网后是否会自动重试。对可能产生外部请求的功能，自动重试还要受用户设置和任务状态约束。
性能要在页面环境里测
浏览器端推理会与页面渲染争用 CPU、内存和主线程时间。单独运行一个推理脚本得到的耗时，不能代表插件嵌入复杂页面后的体验。测试时应记录模型加载、输入预处理、实际推理和界面更新各阶段的耗时，并观察页面滚动、输入和切换标签页是否受影响。
这里不需要急着追求一个漂亮的平均值。先找长尾：首次加载是否明显变慢，连续处理多个片段后内存是否回落，用户取消后后台任务是否真正结束。若推理只能放在主线程执行，界面至少要给出可取消的进度状态；能放入 Worker 的计算，则要验证消息传递和资源释放，不要让已关闭页面的任务继续占用资源。
权限与数据流要能解释
插件申请的权限应与功能逐项对应。能够在当前标签页处理选中内容，就不要为了方便申请所有站点的长期读取权限。输入进入模型前，先确认处理发生在本地还是远端；若会发送到服务端，应向用户展示范围，并避免默认上传整页内容。
日志只保留版本、输入规模、耗时区间和错误类型。页面地址、正文、表单字段以及生成结果不应默认记录。调试需要样本时，使用专门构造的页面，并把收集开关与正式版本分开。
演示通过之后还要做什么
评估时既看结果是否符合任务，也看失败是否可解释、能否恢复。固定同一批页面，在首次安装、缓存已建立、离线、权限被拒绝和模型资源损坏等状态下重复执行。确认插件不会卡住页面，不会在用户取消后继续处理，也不会因为一次失败反复请求资源。
演示通过只说明那几个样例能工作。是否适合更广泛安装，还要看浏览器版本、设备资源、页面类型和权限策略。把这些适用条件写进发布说明，比一句“支持任意网页”更诚实，也能减少用户把边界问题误认为随机故障。
