Lighthouse CI 不是 HTML 库，需通过 CI 流程访问页面审计；lhci autorun 默认不拦截低分，必须显式配置 assert.assertions（如"categories:accessibility": ["error", {"minScore": 0.9}]）才能使构建失败。
HTML项目本身不能“引入”Lighthouse——它不是库、不提供import或<script></script>接入方式；所谓“持续度量”，实际是通过外部工具在构建或部署流程中访问你的 HTML 页面并审计，而非修改或嵌入 HTML 代码。
Chrome DevTools 里跑 Lighthouse 就够用？
对单页快速验证足够，但不构成“持续度量”。它不保存历史、不对比趋势、不拦截低分发布。你点一次，出一份报告，关掉就没了。真正要持续，必须脱离手动点击场景。
- 只适合开发阶段抽查，比如改完表单后验证
label/for是否匹配 - 无法覆盖多 URL（如 /、/about、/contact）批量扫描
- 不记录每次 PR 的分数变化，没法回答“这次提交让可访问性下降了 12 分吗？”
CI 中用 lhci autorun 需要哪些硬性前提
不是装上就能跑，漏掉任一环节，lhci autorun 会静默成功但实际没采集数据，或采集了却没断言、没失败。
-
collect.url必须指向一个能返回 HTML 的 HTTP 地址，例如http://localhost:3000—— 不能是file://协议，也不能是构建产物目录路径（如./dist） - 服务必须已启动且响应 200：常见错误是
serve -s dist命令没加&后台运行，导致后续步骤卡住 -
assert.assertions必须显式配置，例如"categories:accessibility": ["error", {"minScore": 0.9}]—— 不写这条，哪怕得分是 0.3，CI 也绿灯通过 -
upload.target推荐用"temporary-public-storage"，避免本地部署lhci server的运维负担
lighthouse CLI 和 lhci 有什么本质区别
lighthouse 是单次审计命令，lhci 是为 CI 设计的管道化工具；混用会导致预期外行为。
立即学习“前端免费学习笔记（深入）”；
-
lighthouse https://example.com --only-categories=accessibility,seo输出报告后就结束，不存档、不比对、不触发失败 -
lhci collect会默认采集多个 URL（若配置了collect.urls），并把结果推送到存储后供lhci assert检查 - 在 GitHub Actions 中误用
lighthouse替代lhci，会导致“报告生成了但没人看”，因为没有assert步骤，也无法关联到 PR 界面 -
lhci内置重试、超时控制和 Chrome 实例管理，而lighthouseCLI 需手动传--chrome-flags="--no-sandbox"等参数适配 CI 环境
最容易被忽略的其实是环境一致性：本地 lhci autorun 得分 95，CI 里掉到 60，大概率不是 HTML 写得差，而是 CI 容器里 Node 版本过低、Chrome 未启用 sandbox、或页面 JS 渲染完成前就触发审计——这些都不会报错，只会让 LCP、CLS 等指标失真。
