Lighthouse 怎么查看可访问性报告：Audits 面板、问题定位与回归核对

页面上线交付前，很多开发或测试会先跑一次 Lighthouse，却只盯着最顶部的总分看。更实用的用法是把它当成可反复复核的界面校验工具：先从 Chrome DevTools 的 Lighthouse 面板选好设备和审计分类，再顺着报告里的失败项回到页面定位问题，改完之后重新生成报告核对改动效果。

Lighthouse 适合检查什么，入口在哪里

Lighthouse 是 Chrome DevTools 自带的自动化审计工具，不管是公开可访问的页面，还是需要登录鉴权的内部页面，都能直接生成对应报告。它把性能、可访问性、最佳实践、SEO 等审计类别都整合在同一个面板里。如果要检查的是本地开发环境的页面、或者登录后才能进入的页面，优先用 DevTools 自带的这套流程操作，别把页面内容复制到外部第三方服务里跑，避免丢失真实运行上下文导致结果不准。

打开你要检查的目标页面，按 Command + Option + I（macOS 系统）或者 Ctrl + Shift + I（Windows/Linux 系统）唤起 DevTools，在顶部的标签栏里找到 Lighthouse 选项点进去。要是标签被折叠到右侧的更多标签菜单里，先展开菜单就能找到。

运行报告前，先把三个界面选项对齐

第一次点开 Analyze page load 之后，面板会显示报告模式、设备选型和审计类别三个选项，别着急直接点运行，先把这次的检查条件记下来。不同设备和模式下跑出来的页面行为完全不一样，后续回归校验的时候如果条件变了，分数的涨跌根本没有参考可比性。

常规操作路径是先点击 Analyze page load，勾选好你需要的审计类别，再点 Run audit 启动任务。生成报告通常需要几十秒时间，这期间别切走页面也别关闭 DevTools，不然生成的结果没有参考价值，不适合拿来做前后对比。

Accessibility 报告怎么看：先找失败项，再回页面核对

可访问性报告里的每条审计规则通常只有通过或者失败两种状态，不存在“部分通过”的情况。举个例子，页面里有一个按钮缺了可访问名称，哪怕其他所有按钮的语义都写得完全合规，这条审计规则还是会直接判定为失败。报告给出的类别总分只能用来快速判断整体趋势，具体要改的内容肯定要落到具体的失败审计项、对应元素和官方给出的修复建议上。

处理失败项可以顺着下面的步骤走，不容易漏东西：

1. 在生成的报告里打开 Accessibility 分类，先把失败的审计规则名称记录下来。
2. 展开对应的失败项，查看里面列出的受影响元素或者示例节点，确认它对应页面上的哪个业务组件。
3. 切回 Elements 面板或者直接看页面源码，检查对应元素的语义、可见文本、键盘焦点和颜色对比度，别照着提示机械改标签就完事。
4. 改完代码之后，保持访问 URL、设备选型和勾选的审计类别不变，再重新跑一次新的报告。

比如“按钮没有可访问名称”这个问题，不一定只是少写了一个文本节点：图标按钮可能是缺了可识别的 aria-label 标注，表单控件则可能是它和关联的 label 标签没绑定对。报告只会告诉你哪里不符合预设规则，组件的实际语义和交互意图，还是得结合页面的业务场景自己判断。

修复后如何做回归核对

回归校验不是看到分数变绿就完事。先用完全相同的页面和相同的设备重新运行审计，确认之前的目标失败项已经变成通过状态，还要顺便检查有没有因为这次改动引入新的失败项。面对动态加载的页面，建议等页面所有状态都稳定下来再启动审计，避免弹窗、异步加载的列表或者登录跳转操作把结果带偏。

• 条件一致：访问URL、设备选型、运行模式和审计类别必须和上一份参考报告完全一样。
• 目标消失：之前记录的失败项，不再出现在新报告的失败列表里。
• 范围可解释：如果出现新增的失败项，要能说清楚出现的原因，不能直接用总分合格把问题盖过去。
• 证据留存：导出保存报告，或者记录下当时的页面版本和关键审计项的状态，留作后续溯源的凭证。

Lighthouse 官方文档也提到，审计结果更像是帮你找优化方向的线索，而不是判定产品质量的唯一标准。真实用户的使用体验，还要配合人工键盘操作、屏幕阅读器朗读测试和实际业务流程验收才能最终确认。

常见问题

为什么同一个页面每次跑出来的 Lighthouse 分数不完全一样？

网络波动、缓存状态、本地CPU负载和页面未完成的异步请求，都会导致结果有小幅波动。做回归校验的时候固定设备和运行模式，等页面状态完全稳定之后再重复跑几次检查就行，别把单次的小幅分数波动直接当成代码回退。

Accessibility 分数很高，是不是代表页面已经完全符合无障碍要求？

不是。自动审计只能覆盖可以通过程序逻辑判断的规则，像键盘操作路径、焦点跳转顺序、屏幕阅读器实际朗读体验这类场景，还是要靠人工逐一检查。

本地开发的页面能不能直接用 Lighthouse 审计？

可以。Chrome DevTools 自带的这套工作流完全适配本地环境和需要登录的页面，直接在目标开发页面打开 DevTools 运行审计就好。

修复完一个失败项之后，要不要重新勾选所有审计类别重跑全量？

不用。如果本次迭代只处理可访问性相关问题，就保持相同设备和对应审计类别重跑就行，等到准备上线交付的阶段，再按项目的校验清单补跑其他类别的全量审计。

把 Lighthouse 用成“运行条件可复现、失败项可定位、修复后可回归”的常规检查工具，跑出来的报告分数才会有实际参考价值。最小的校验闭环就是：选定待检查页面和适配的设备，启动审计，定位失败项，改完之后用完全相同的条件复测一次。