站在开源项目肩膀上：我从 Dark Reader 学到什么
开发 Night Safari 时，我去看了 Dark Reader 的实现。想知道一个成熟的深色模式项目，为什么能处理那么多页面情况，也想判断哪些能力值得复用。
后来，Night 接入了本地打包的 Dark Reader API 引擎。我从中学到的，不只是怎样调用启用函数，还包括怎样划分职责和检查兼容范围。
先看它在处理什么层次
如果只遍历页面元素，修改眼前看到的颜色，容易漏掉悬停状态、稍后出现的菜单，以及网站动态修改的样式。
Dark Reader 的动态主题实现包含颜色修改、样式表管理和变量处理等部分。这让我开始从样式规则与变化来源理解网页，而不只是逐个看元素当前的颜色。
上游也维护动态主题的网站修正规则，针对通用策略处理不了的情况给出适配。Dark Reader 贡献指南
成熟度有一部分来自这些积累：结构相似的页面，实际仍然会有不同的边缘情况。
复用之后，我还负责什么
Night 负责原生主题优先、网站策略、开关、加载保护和 Safari 使用体验；Dark Reader 负责需要转换时的动态主题处理。
这样的划分让我可以把精力放在使用问题上。例如，网站已经有可靠的深色主题，应该保留它；只有局部遗漏时，需要考虑补齐；用户关闭扩展后，应当恢复页面。
这些判断不会因为引擎接入而自动完成。
API 引擎与完整扩展有区别
Dark Reader 提供 enable、disable 等 API，可以嵌入其他项目。它们的接口可以直接查上游定义。Dark Reader API
但 Night 当前嵌入的是 API 动态主题引擎，没有自动带入完整扩展的网站修正规则库。为了 Safari 环境采取的一些配置，也会影响动态样式的覆盖范围。
因此，不能把上游产品的全部兼容性直接当成自己产品的能力。实际网站、权限、跨域资源和特殊结构，仍然需要单独验证。
来源、版本和测试，都值得保留
我在项目里保留了引擎版本、源码 revision 与文件摘要。打包时检查引用文件和 ZIP 完整性，帮助确认交付的包带着哪一版引擎。
升级时，也需要重新检查常用场景。上游改进了一个问题，不保证我的主题判断与加载逻辑仍然配合正确。
测试记录要说明使用了什么浏览器、是否为真实扩展、覆盖了哪些操作。对 Night 来说，Chrome 回归有价值，但不能代替 Safari 的权限、弹窗和注入检查。
许可证也是项目的一部分
Dark Reader 使用 MIT 许可证，随项目保留版权与许可文本是复用时需要做的工作。我没有把引擎实现写成自己独立开发的成果。上游许可证
介绍产品时，也应该讲清楚哪些部分来自上游，哪些是自己的策略与适配。这能让读者理解项目真正解决了什么。
我现在怎样决定复用
我会先看需要的能力是否与上游职责吻合，再考虑接口、运行环境和维护成本。接入之后，还需要能定位问题、更新组件，并验证自己的使用流程。
对我来说，站在开源项目肩膀上，是在已有积累上继续做适合自己场景的事情。也正因为可以读源码，我才有机会理解那些看起来很自然的体验，背后是怎样一点点做出来的。
自己的项目：Night Safari