缘起
最近对 angelife 的前端代码做了一次全面审计。起因很简单：项目里有不少 2011 年遗留的旧 jQuery 脚本、手写的搜索代码、以及主题切换这类现代浏览器已经原生支持的基础功能。直觉告诉我"应该用新东西替换掉它们"。
但真正动笔审计时，我发现了一个问题：我找不到一个可靠的判断标准来决定"什么值得换"。
CSS Anchor Positioning 看起来很美，但实际浏览器支持率如何？Container Queries 号称 2025 年的 Baseline，但我当前项目的浏览器分布真的能安全使用吗？更关键的是——替换一个可工作、可读、可调试的实现，收益到底有多大？
这个问题没有通用的答案。所以我决定先定规矩，再动手。
Google Baseline：不再是猜兼容性
Google 的 Web.dev 团队维护了一份 Baseline 标准，把所有 Web 能力分为三个状态：
- Widely Available：被主流浏览器稳定支持超过 30 个月，可以放心用
- Newly Available：刚被浏览器支持，但尚未跨生态普及
- Limited availability：只有部分浏览器支持
这个分类看似简单，但在工程决策中非常实用。
举个例子：light-dark() CSS 函数在 2024 年成为 Baseline，到 2026 年已经属于 Widely Available。而 CSS Anchor Positioning 在 2025 年中进入 Baseline，到 2026 年中仍属于 Newly Available。
按照 Baseline 框架，“能不能用"就有了客观依据——而不是靠"我觉得浏览器应该支持了”。
三个戒律
我把这次审计的规则写进了项目的 .hermes_rules，核心是三条：
1. 拒绝追新强迫症
严禁为了使用新特性而盲目推翻现有清晰（Clear）、显式（Explicit）、可调试的业务逻辑。现有的稳定实现通常就是最现代的。
这是最重要的一条。一个用 var 写的 2015 年脚本，如果它可读、可调试、无 bug，那它比一个用了 2026 年最新 API 但引入闭包陷阱、调试困难、依赖链复杂的"现代"方案更优秀。
代码的终极目标是服务用户和开发者，不是服务简历。
2. Baseline 动态审查机制
在推荐或引入任何"现代化"Web 能力前，必须先通过底层工具或访问 Web.dev Baseline 检查其真实兼容性状态。
这就是 Google Baseline 框架的实际应用。不再凭印象判断兼容性，而是查表。
3. 重构准则
只有当新方案能够显著降低代码复杂度（如消灭复杂的第三方依赖）、且其技术指标已达到 Baseline 的 Widely Available 标准时，才允许提出重构建议。任何 Newly Available 的特性必须提供完备的 Polyfill 或降级兜底方案。
这把重构的门槛提得很高。本质上，重构的默认答案是"不"，除非你能同时满足两个条件。
三条戒律下的实际决策
有了这套标准后，回头看审计初稿，大部分推荐被枪毙了：
| 原推荐 | 新标准下 | 原因 |
|---|---|---|
light-dark() 替代 JS 主题切换 | ✅ 通过 | Widely Available，且 JS 从 91→47 行 |
| Fuse.js 替代手写搜索 | ❌ 驳回 | 引入第三方库代替清晰的原生代码，违背"拒绝追新" |
| CSS @container 替换 @media 断点 | ❌ 驳回 | Newly Available，无降级方案 |
| CSS Anchor Positioning 重构布局 | ❌ 驳回 | Newly Available，无降级方案 |
| 删除旧站 jQuery 等遗留脚本 | ❌ 不必要 | 不影响功能，删了只是精度洁癖 |
| 旧站加评论 | ✅ 通过 | 用已有 Giscus 配置，无新依赖 |
| Kindle 全站优化 | ✅ 通过 | 复用已有基础设施，不引入新框架 |
最终真正落地的修改只有：
- 主题切换 JS 瘦身（91→47 行）：纯做减法，去掉与内联脚本重复的初始化流程和过时的 API 回退
- 旧站集成 Giscus 评论（186 页）：利用项目已有的 GitHub Discussions 配置，复用不新增
- 统一全站搜索：
index.json合并新旧站共 353 条索引，search.js支持?q=URL 参数 - Kindle 阅读版全站覆盖：新站文章 + 旧站 80 篇文档在
/kindle/下统一呈现
教训：少即是多
这次最大的收获不是学会了什么新技术，而是建立了一套拒绝的机制。
工程上最有价值的技能不是"什么都能做"，而是"知道什么不该做"。Google Baseline 提供了一个客观的参照系。但更重要的，是那个第一条：现有的稳定实现通常就是最现代的。
下次你写技术方案时，不妨先问自己三个问题：
- 这个改动有可量化的收益吗？（减少依赖？降低复杂度？）
- 目标技术在 Baseline 中处于什么状态？
- 最关键的——你是在解决问题，还是在追新？