站点扩展上线前自检表

扩展类商品最容易出现的落差是：装上去跑得通，用两周开始出问题。问题往往不在代码本身，而在上线前没人逐项确认边界条件。下面这份自检表按四个维度组织，可以当作发布前的固定动作，也可以当作验收别人交付物时的核对依据。

一、权限与触发范围
先列一张权限清单，把扩展声明的每一项能力写成一句话：它能读取什么、能修改什么、在什么条件下才会被激活。然后逐项反问：如果这一项被关掉，功能会退化成什么样？很多扩展把大量能力打包在默认开启状态，用户一旦收紧权限就整块失效，这类设计在审核环节容易被退回，在真实使用中也容易引发信任问题。检查要点包括：激活条件是否由用户显式触发而非静默运行；是否存在读取整页内容的必要性，能否缩小到特定区域；权限变更后是否需要重新加载页面，交互提示是否清楚。还要确认扩展在无权限、部分权限、全部权限三种状态下的表现，最好三种都能给出可见反馈，而不是静默失败。

二、兼容性与环境差异
把目标使用环境列成矩阵：不同内核版本、不同窗口尺寸、有无深色模式、有无其他同类扩展共存。逐个组合走一遍核心路径，记录哪些组合下出现错位、遮挡或功能失效。重点看三类问题：一是样式注入与宿主页面样式冲突，表现为按钮被覆盖或布局被撑开；二是事件监听重复绑定，表现为一次操作触发两次；三是存储读写竞争，表现为设置项刷新后回退。对每一类问题，自检时要确认是否有隔离手段，例如作用域限定、命名前缀、读写加锁或版本号判断。兼容性结论不要写成“基本正常”，要写成“在哪些组合下通过、哪些组合下需要降级”。

三、降级与异常路径
正常路径跑通只完成一半。自检时人为制造异常：断网、接口返回空数据、返回超长文本、返回格式不符、本地存储被清空、用户连续快速点击。观察扩展是卡死、报错弹窗，还是安静地退回默认状态。合格的表现是：核心功能有明确的兜底值，非核心功能可以整体关闭而不影响主流程，错误提示只说必要信息、不暴露内部细节。还要检查卸载路径：卸载后是否残留注入的样式、监听器、临时数据；重新安装后是否能干净初始化。残留是长期使用中最常见的隐性故障源。

四、交付前的固定动作
把上述内容固化成一张可勾选的清单，每次发布前逐项打勾并记录结论。清单之外再加三条纪律：改动权限或激活逻辑必须整体回归，不能只测改动点；任何降级分支都要有可观测的日志或状态标记，便于事后定位；版本说明只描述行为变化，不承诺无法验证的效果。做到这几点，扩展的维护成本会明显下降，用户遇到的意外也会少很多。