归档与更新说明： 本文归入 2018 年 Chromium 二次开发专题，并于 2026-09-28 重新整理。Chromium 的分支、构建参数和依赖变化很快，实际操作请同时核对对应版本的官方文档与源码。
Chromium fork 最昂贵的阶段通常不是第一次发布，而是第二次、第三次以及每一次安全更新。分支偏离上游越久，合并成本和未知风险就越高。
控制补丁面
将定制拆成小而独立的提交，每个提交只解决一个问题，并附带测试或可重复的验证步骤。尽量通过配置、资源覆盖和边界清晰的组件实现需求，避免在核心路径散布大量条件判断。
推荐为每个补丁记录：
- 业务目标和负责人；
- 修改的上游模块；
- 支持平台；
- 自动化测试和人工验收步骤；
- 上游是否已有相似实现；
- 移除这个补丁的条件。
跟随上游
建立固定节奏获取上游版本与安全修复，不要等到漏洞公开后才临时研究构建系统。同步流程至少包括：拉取目标版本、重放本地补丁、解决冲突、全量构建、自动化测试、签名和灰度发布。
测试层次
- 单元测试覆盖独立逻辑。
- Browser tests 覆盖 UI、profile、网络和进程交互。
- 安装与升级测试验证真实发布包。
- 冒烟测试覆盖启动、导航、下载、证书、代理、扩展和更新。
- 性能与稳定性基线观察启动时间、内存、崩溃率和页面指标。
发布与回滚
发布产物必须可追溯到源码 revision、补丁集合、工具链和构建参数。签名密钥应与普通构建环境隔离。灰度发布要能暂停，客户端更新器要验证签名，并且提前定义回滚对用户 profile 的影响。
安全响应
维护者需要持续关注 Chromium 发布与安全信息，评估漏洞是否影响自己的分支。隐藏版本号或延迟公开并不能修复漏洞；真正有效的是缩短从上游修复到用户完成更新的时间。
可从 Chromium Dash 了解版本节奏，并在 Chromium Security 阅读安全相关资料。
一个可持续的 fork，应尽可能接近上游，并让每个差异都可解释、可测试、可移除。
暂无评论