直接在chrome devtools中打开lighthouse面板即可运行审计，无需修改html；但html结构缺陷（如img缺alt、label与input的for/id不匹配）会因静态dom扫描而直接拉低accessibility和seo得分。
直接在 Chrome DevTools 里点一下就能出分，不需要改 HTML 也能跑，但 HTML 写法会立刻拉低 Accessibility 和 SEO 得分。
Chrome DevTools 里怎么打开 Lighthouse 面板
新版 Chrome（≥ v110）已原生集成，无需插件或命令行：
- 打开目标网页，确保页面完全加载完成（Network 面板无 pending 请求，不是重定向中或空白页）
- 按
Ctrl+Shift+I（Windows/Linux）或Cmd+Option+I（macOS）唤出 DevTools - 点击顶部标签栏的
Lighthouse—— 若没看到，点右上角⋯→More tools→Lighthouse - 勾选要审计的类别：
Performance、Accessibility、SEO（其他如Best Practices或PWA可按需取消） - 设备选
Mobile或Desktop：移动模式会模拟 UA 和 viewport，影响渲染后 DOM 结构，间接改变无障碍节点可见性 - 模式保持默认
Navigation（不是Timespan或Snapshot），否则Accessibility不出总分 - 点击
Analyze page load（不是旧版文案Generate report）
为什么 img 缺 alt、label 和 input 的 for/id 不匹配会直接扣分
Lighthouse 的 Accessibility 和 SEO 审计不执行 JS，只静态扫描 DOM 树和属性。所有扣分项都来自 HTML 层面硬伤：
-
<img>没alt属性，或alt=""却没加role="presentation"（装饰图必须显式声明） -
<input id="email">有for="email"，但拼错成for="emial"或大小写不一致 - 用
<div onclick="submit()"> 模拟按钮，却没加 <code>role="button" tabindex="0" - 导航菜单没包在
<nav></nav>里，主标题跳级（如<h1></h1>后直接<h3></h3>） - 文本颜色靠内联样式写死（如
style="color:#333"），Lighthouse 难以准确提取对比度 - 用
--only-categories=accessibility,seo聚焦 HTML 问题，省时间且避免干扰 - 加
--emulated-form-factor=mobile：移动端模拟会影响 viewport 和 UA，间接改变语义化上下文 - 加
--throttling-method=devtools：确保网络节流真实，防止因资源加载失败导致 DOM 元素未渲染而漏检 - 示例命令：
lighthouse https://example.com --only-categories=accessibility,seo --emulated-form-factor=mobile --output=html --output-path=./report.html --view - 必须禁用所有浏览器扩展（尤其是广告屏蔽、Dark Mode 类插件），它们可能往 DOM 注入元素或覆盖样式
- 别在隐身窗口测试——某些扩展在隐身模式下仍生效，且 Lighthouse 无法捕获 Service Worker 缓存行为
- 不要依赖“刷新完立刻点 Analyze”，等 Network 面板确认全部请求完成（无 pending 状态）再运行
- 测试前确保页面不是由 JS 动态注入关键语义结构（比如用 JS 插入
<nav></nav>或<label></label>），Lighthouse 扫不到
命令行运行时怎么聚焦 HTML 相关审计
CLI 方式适合 CI 或批量检测，关键参数要对得上 HTML 层面检查逻辑：
最容易被忽略的测试干扰项
分数低却找不到原因？问题常不在 HTML 本身，而在测试环境：
真正卡分的点往往藏在细节里：一个拼错的 id、一个漏掉的 role="presentation"、一次没关掉的广告拦截插件，就足以让 Accessibility 分数掉 20+。别只盯着报告里的建议条目，先确认测试环境干净、DOM 是你写的那个 DOM。
