Lighthouse 13：用 Chrome 官方审计器把性能问题钉在报告里

它解决什么问题，给谁用

Lighthouse 解决的是网页质量评估的碎片化问题。过去要分别测加载速度、检查图片 alt 文本、验证 meta 描述，每个环节都要单独写脚本或手动点开 DevTools。Lighthouse 把性能、可访问性、SEO、PWA 和最佳实践合并成一次运行，输出统一报告。它面向两类人：一类是前端工程师，想在发布前快速知道页面有没有明显问题；另一类是平台或运维团队，需要把质量检查嵌入 CI，让每次提交都跑一遍审计。仓库描述写得很直白，它分析网页并收集现代性能指标和开发者最佳实践洞察。它的定位不是实时监控，而是快照式体检。

采集与审计分离的两次运行机制

Lighthouse 的核心设计是 gather 和 audit 两个阶段分离。gather 阶段启动浏览器，访问目标 URL，收集 trace、DOM 快照、网络请求记录等原始材料。audit 阶段不再碰浏览器，只对着这些材料跑规则，算出分数和结论。这种分离带来一个实际好处：你可以用 -G 只采集一次，把产物存到磁盘，之后反复用 -A 跑不同配置的审计，不用重新加载页面。对调试很有用，因为网络波动只影响采集那一次，后续审计完全可复现。README 里明确写了 -G 会启动浏览器、收集 artifacts、存到 ./latest-run/ 然后退出，-A 则跳过浏览器交互，直接从磁盘加载材料。这种设计也意味着审计规则可以独立于浏览器版本演化，只要采集格式稳定。

从 DevTools 到 Node CLI 的三条入口

使用方式分三层。最轻的是 Chrome DevTools 自带的 Lighthouse 面板，装好 Chrome 就能用，点 Generate report 出结果，适合临时检查。中间是 Chrome 扩展，功能与 DevTools 版类似，适合不想开 DevTools 的人。最重的是 Node CLI，这也是自动化场景的主力。安装命令是 npm install -g lighthouse，运行 lighthouse https://airhorner.com/ 默认输出 HTML 报告。CLI 支持 --output json 把结果打到 stdout，或者 --output html --output-path ./report.html 指定文件名。有个细节值得注意：如果同时指定多个格式和 output-path，扩展名会被忽略，文件会按 <name>.report.json 和 <name>.report.html 的规则保存。这个行为在 README 的示例里专门用 NOTE 标出，容易踩坑。

配置与生命周期控制的真实边界

CLI 的配置选项比表面看起来要多。--save-assets 能把 trace 和 devtools 日志存盘，--list-all-audits 列出所有可用审计项，--list-trace-categories 列出需要的 trace 类别。这些对调试自定义审计很有用。生命周期控制通过 -G、-A、-GA 三个旗标实现，可以组合成只采集、只审计、或采集加审计并保存产物。你甚至可以给 -GA 指定自定义目录，比如 -GA=./gmailartifacts https://gmail.com，把产物放到指定位置。但配置的深度有限，README 只给了 CLI 层的选项，更复杂的配置要去看 docs/configuration.md。对普通用户来说，CLI 的默认配置已经足够，想调网络节流或设备模拟得翻文档。另一个限制是 Node 版本要求，README 明确说需要 Node 22 LTS 或更高，老项目可能要升级环境。

报告格式与共享的实用细节

报告默认是 HTML，适合人看。JSON 输出适合程序处理，可以喂给 CI 或自定义仪表盘。HTML 报告顶部有 Export 按钮，可以把报告上传到 Lighthouse Viewer，拖拽 JSON 文件即可在线查看。共享功能依赖 GitHub 登录，报告会以 secret Gist 形式存到你的账户下。这里有个隐私点：共享意味着报告内容会离开你的机器，虽然 Gist 是 secret，但账号关联是明确的。如果你处理的是敏感页面，共享前要想清楚。另外，第一次运行 CLI 时会弹出匿名错误上报的询问，可以拒绝，不影响功能。这个机制说明 Lighthouse 团队依赖用户遥测来发现 bug，但把选择权交给了用户。

一个绕不开的局限：模拟环境与方差

Lighthouse 跑在受控的浏览器环境里，用模拟的网络节流和设备参数，这决定了它的分数是实验室数据，不是真实用户体验。README 里专门有一份文档叫 Dealing with variance，说明官方承认结果有波动。网络抖动、后台进程、DNS 缓存都可能影响 gather 阶段的数据，进而改变分数。这意味着你不能把两次运行的分数差 1 分当作真实变化。更根本的问题是，Lighthouse 的默认配置偏向移动端模拟，对桌面站点的评估可能不贴合实际。如果你需要的是真实用户的分布数据，比如 p75 的 LCP，Lighthouse 给不了。它适合找问题，不适合做容量规划或性能预算的唯一依据。

替代方案：Playwright 自建采集与 CrUX 真实数据

如果你觉得 Lighthouse 的审计规则太固定，或想完全控制采集环境，Playwright 是更底层的选择。Playwright 可以启动 Chromium、Firefox 或 WebKit，手动设置网络节流、设备模拟，自己记录 performance entries 和 trace。差别在于，Playwright 只提供采集能力，没有现成的审计规则集。你得自己定义什么算通过，什么算失败。另一类替代是 Chrome UX Report（CrUX），它基于真实 Chrome 用户的现场数据，能反映真实分布。CrUX 与 Lighthouse 互补：前者告诉你用户实际体验如何，后者告诉你为什么可能差。如果你只想用官方指标，可以只跑 Lighthouse 的 performance 类别，但那样会失去可访问性和 SEO 的检查。选择的关键是看你要的是可复现的诊断，还是真实世界的概览。

维护成本与许可证的实际情况

Lighthouse 的维护节奏相当活跃，v13.4.1 在 2026 年 7 月发布，距离 v13.4.0 只有一个月左右。这意味着你需要跟上版本更新，因为审计规则和指标定义会随 Chrome 演进。升级成本主要在配置兼容性，比如自定义审计可能依赖内部 API，版本升级可能破坏。仓库没有提供迁移指南，但 docs 目录里有配置文档，可以对照检查。许可证是 Apache-2.0，允许商用和修改，但要注意保留版权声明。它不附带任何担保，官方 FAQ 里也说明错误上报是匿名的，但如果你修改源码并分发，需要遵守 Apache 的条款。整体来说，维护成本不算高，因为主流使用方式就是 CLI 或模块，不需要自己改源码。但如果你深度定制，就要承担每次升级的回归风险。

编辑结论

Lighthouse 适合需要标准化、可重复的页面质量审计的团队，尤其是已经依赖 Chrome DevTools 或 CI 流水线的场景。它不适合作为唯一性能标准，因为分数受网络与设备模拟影响，且无法覆盖真实用户环境。若你追求实验室数据与现场数据的结合，应搭配 CrUX 或 RUM 工具。采用前先验证：Node 22 环境是否就绪，报告中的指标是否与你的业务目标对齐，以及是否接受默认的移动端模拟配置。若需要更细粒度的控制，可改用 Playwright 自建采集，但会失去现成的审计规则集。最终判断：Lighthouse 是当前最完整的开源审计框架，但它的价值取决于你是否愿意接受其预设的评估视角。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes