把质量门禁写进 CI

分层

门禁不是“多跑几个测试”，而是每一层回答不同的问题：

• 单元测试回答“纯函数算对了吗”，覆盖筛选、排序、SEO、JSON-LD 与阅读时长。
• 构建产物校验回答“页面真的生成了吗”，检查页面数量、canonical 唯一性、sitemap、RSS、OG 与内部链接。
• E2E 回答“用户真的能完成操作吗”，覆盖筛选、搜索、视图过渡、主题与打印。
• axe 回答“辅助技术能用吗”，对关键页面做自动化扫描。
• Lighthouse 回答“体验达标吗”，用预算约束 LCP、CLS、TBT 与四项分数。

预算

只跑分数不够，分数会波动。更稳的做法是同时约束体积：首页 JS、详情页 JS、CSS、字体与 HTML 都有 gzip 上限，超出即失败。这样性能回归会在合并前暴露，而不是上线后才发现。

一次事故

项目早期，项目库的筛选栏用 hidden 属性隐藏，等脚本加载后再显示。Lighthouse 测出 CLS 0.27，Performance 只有 0.86——内容在首屏之后整体下移。

修复方式不是加动画，而是让布局从第一帧就稳定：把“是否显示”交给首屏前写入的 .js 类，脚本只负责绑定事件。修复后 CLS 降到接近 0，Performance 回到 1.0。

结论

门禁的价值在于“让正确的做法成为默认路径”。当预算、可访问性与测试都写进 CI，维护者不需要每次凭记忆检查，只需要让流水线绿。相关决策见 ADR 0008，具体阈值见项目文档的性能章节。

实现索引

• .github/workflows/ci.yml：格式、类型、测试、构建、E2E、axe 与预算。
• scripts/check-*.mjs：产物、SEO、链接、对比度与体积检查。
• lighthouserc.json：Lighthouse CI 的页面集合与断言。