修改多浏览器扩展，同时不泄露机密、不破坏已存数据

## 先找出受影响的扩展层及其本地规则 修改代码前，应先确定受影响的层：后台逻辑、用户界面、共享实用工具、浏览器声明、构建工具、测试或已存储状态的升级。编辑前请阅读距离最近的层级专用说明；工作流自动化文件通常还有额外的连接配置和合并队列规则。 使用由仓库管理的运行时和包管理器包装程序。将配置保存在指定的本地环境文件中，绝不能放入受版本控制的源代码。每个新实现文件都应优先使用当前的类型化语言；旧有的无类型文件可以保留，直到所请求的变更足以证明转换是合理的。 使用为各类文件指定的格式化工具。代码格式化工具负责类型化文件和组件文件，结构化数据格式化工具负责包数据和配置数据。交接前应对变更文件执行格式化、静态类型检查、lint检查和循环依赖检查。 保持函数职责集中，使用提前返回减少嵌套，仅在提取能明确所有权时消除重复逻辑，并且不要留下调试日志或已注释掉的代码。 ## 机密只留在本地，依赖变更后重新生成策略 将API凭据、监控端点、测试密码和签名材料视为本地机密信息。提供有文档说明的占位值，但绝不能提交真实值，也不能在诊断日志中包含敏感状态。 依赖项的每次添加、升级或移除都是一次供应链变更。请完成全部流程： 1. 更新包声明和锁文件。 2. 通过受支持的命令对锁文件去重。 3. 重新计算允许运行安装脚本的包白名单。 4. 重新生成用于限制依赖项访问宿主API的能力策略。 5. 重新生成第三方归属信息。 6. 启用生产安全策略后执行构建和测试。 将所有生成的策略和归属信息变更纳入同一次评审。未应用策略的开发构建可以用于快速迭代，但绝不能替代受保护的最终构建。应在目标平台上重新生成与平台相关的策略，不要为了让构建通过而削弱策略。 ## 用明确声明的状态和领域操作设计后台控制器 使用控制器处理后台业务逻辑以及子系统之间基于消息的通信。对于每个存储的属性，应声明它是否匿名、能否安全用于诊断快照或状态日志、是否持久化，以及是否由界面使用。 遵循以下状态规则： - 导出一个每次返回新对象的默认状态工厂，绝不要使用共享的可变默认对象。 - 通过一个命名的选项对象接收构造函数依赖项，而不是使用位置参数。 - 对添加、移除、批准或拒绝等领域操作建模；避免使用通用字段设置器。 - 只存储必要状态，并通过导出的选择器派生计数、标志和投影。 - 更新状态前验证操作输入。 - 为计时器、订阅、监听器和消息通道实现生命周期清理，然后委托给父级清理。 保持控制器源代码、类型、同目录测试、注册信息和受影响的选择器同步。状态结构发生变化时，还必须增加一个带编号的升级步骤。 ## 把代码放在所属的层，并同步更新相关文件 将可复用的界面组件与其样式、类型、测试、故事、文档和公开导出放在一起。仅供页面使用的组件应放在页面层，仅供后台使用的辅助程序应与后台代码放在一起，真正共享的实用工具、常量和类型则应放在共享模块中。 行为发生变化时，检查直接耦合的文件： - 控制器变更可能还需要修改测试、类型、注册信息和状态升级。 - 组件属性变更可能还需要修改测试、故事、样式、文档和导出。 - 全局状态变更可能还需要修改选择器及使用它们的组件。 - 构建或浏览器声明变更可能还需要目标专用夹具和端到端覆盖。 不要仅仅为了避免选择所有者而复制共享逻辑。将其移至范围最窄的公共层，在需要时使用依赖注入，并解决循环导入，而不是接受不断扩大的例外列表。 ## 为每个浏览器目标和功能标志分别构建和测试 为每种受支持的浏览器声明生成方式维护独立的构建和测试路径。应考虑持久后台页面与服务工作线程、权限模型以及命名空间可用性等方面的差异。 在共享代码中使用跨浏览器API抽象。将不可避免的目标差异隔离在一个小型兼容层中，不要把条件判断分散到各项功能中。 功能标志必须作为明确的构建输入： - 使用有文档说明的本地配置进行可重复的开发。 - 使用单命令环境覆盖进行隔离实验。 - 仅在远程标志测试场景中使用本地声明覆盖。 - 使用与实际交付相同的目标和标志组合进行构建和测试。 如果用户没有指定浏览器，请使用项目文档中规定的默认目标。当请求指定了目标时，应选择与之匹配的开发、生产和端到端命令，不要根据其他构建来臆测兼容性。 ## 编写界面组件，测量后再做优化 使用函数组件和钩子，在边界处解构属性，将仅供本地使用的状态保留在本地，并且只对跨功能数据使用共享状态层。 为了保证渲染正确性和性能： - 动态列表的键应使用稳定的领域标识符，绝不要使用数组位置。 - 在渲染过程中计算派生显示值，不要通过副作用将其复制到状态中。 - 只有重复工作的开销达到实质程度时，才对高成本的排序、筛选或聚合进行记忆化。 - 当引用变化导致重新渲染时，应稳定传递给已记忆化子组件的回调。 - 在组件外部定义真正静态的对象和样式。 - 对大型列表，应在测量渲染开销后再考虑虚拟化。 输入不可变时，应先复制再排序。优先分析频繁渲染或计算开销高的组件；没有证据时，不要给简单且很少渲染的组件添加记忆化。 ## 先用失败的测试重现缺陷，再修复并重测 处理缺陷时，先添加一个能够复现故障的聚焦测试，运行并确认其失败，再实施最小修复并确认测试通过，然后运行直接相关的覆盖测试。将单元测试与源代码放在一起，并通过公开接口而不是私有方法测试行为。 在子系统之间的边界使用集成测试。对真实浏览器工作流使用端到端测试，并先构建专用测试产物。迭代期间可以接受更快的未保护构建；最终验证必须使用生产安全策略和请求指定的浏览器目标。 明确要求进行可视验证时： 1. 启动实际的扩展测试环境。 2. 操作前检查当前屏幕。 3. 使用浏览器控件执行用户流程。 4. 捕获屏幕截图或最终屏幕说明作为证据。 5. 即使失败也要清理测试会话。 如果所需的可视工具不可用，应报告此限制，不得仅凭代码检查就声称已完成可视验证。接受快照变更前应先评审；只有行为变更是有意的，才更新快照。 ## 已存数据结构改变时，编写编号的升级步骤 每当持久化状态的结构发生变化时，都要创建一个带编号的升级。使用仓库工具生成升级，以保持顺序和注册的一致性。 升级必须： - 妥善接受旧的、不完整的以及部分损坏的输入。 - 克隆输入并返回新的状态对象，而不是改变调用方的值。 - 只转换自身负责的版本范围和属性。 - 明确记录目标版本。 - 保留无关的用户数据。 测试有代表性的旧状态、缺失字段、格式错误的可选值、幂等性预期以及精确的新输出。同时运行升级测试，以及使用升级后状态的控制器或功能测试。 ## 按类型区分错误，不关闭检查地修复 更改环境前，先读取第一个可操作的错误。将其归类为格式、类型、依赖项、能力策略、浏览器构建、测试数据、陈旧产物、端口或循环导入故障，然后执行针对该类别范围最窄的诊断。 如果之前通过的测试在变更后失败，应判断是实现发生了回归，还是预期行为被有意更改。只有后一种情况才更新测试，并记录行为层面的原因。 对于端到端故障，应确认存在正确且最新的测试构建，使用调试输出，并且仅在主动检查期间让浏览器保持运行。对于策略故障，应根据已声明的依赖项和宿主访问重新生成策略；不要永久禁用策略执行。 只有在确定准确目标并确认可以安全重新生成后，才能移除缓存、构建输出、已安装的包、浏览器数据或快照。不要把大范围清理作为排查问题的第一步。 ## 只在被要求时执行 Git 提交、推送和评审请求 不要更改仓库配置或运行破坏性的版本控制命令。除非用户明确要求执行相应的特定操作，否则不要暂存、提交、推送或发起评审请求。 获得授权后： - 只暂存属于所请求变更的文件。 - 提交前对变更范围进行格式化和测试。 - 使用仓库的结构化提交约定。 - 只有在请求推送时才执行推送。 - 除非用户明确要求就绪状态，否则发起草稿评审请求。 - 遵循评审模板，并完全隐藏不适用的部分。 手动测试部分必须描述人工操作和可见结果，而不是自动化lint或测试命令。对于可见的界面变更，应包含变更前后的证据，解释不明显的决策，链接相关工作，并在需要时指出面向用户的变更说明。 评审期间，应答复反馈并添加后续提交，而不要重写已经评审的历史记录。合并前，必须确保对话已解决、审批已完成、自动化通过，并采用仓库要求的squash标题。 最后使用与变更规模相称的检查清单：变更文件格式化、类型、循环依赖、聚焦测试、受影响的构建、相关文件、文档、依赖项变更时的生产能力策略，以及请求时提供真实的可视证据。