lighthouse ci默认不拦截低分构建，因其设计哲学是“报告先行，约束后置”；需显式配置assertions（如"categories:accessibility": ["error", {"minscore": 0.9}]）才能使ci失败，否则即使accessibility得分为0，构建仍通过。
没有“开箱即用”的单工具方案，必须按场景组合 axe、Lighthouse、a11y-checker 和 WAVE，且每种集成方式的触发时机和校验深度完全不同。
axe DevTools 浏览器插件怎么配才不漏报
它只在当前页面 DOM 上运行，不执行 JS 渲染前的静态检查，也不覆盖 SSR 或 hydration 失败场景。常见漏报点集中在动态内容未就绪时点击 Run。
- React/Vue 应用务必等
document.querySelector('#root')有子节点后再点扫描，否则aria-live区域、异步加载的表单控件全被跳过 - 若页面含
document.write()或未关闭的<script></script>标签，iOS Safari 远程调试下会卡白屏，axe 无法注入——先关掉 Web Inspector 再试 - 插件默认禁用部分规则（如
color-contrast），需进 Settings → Rules 手动勾选，否则对比度问题不会出现在报告里
Lighthouse CI 中 assert.categories:accessibility 失效的三个原因
不是配置写错，而是环境或采集阶段就断了链路。CI 里跑出 accessibility 得分 0 却不报错，大概率是以下其一。
-
collect.url返回 404 或重定向：确保npx serve -s dist -p 3000已启动，且lhci collect访问的是http://localhost:3000而非http://127.0.0.1:3000（某些镜像 DNS 解析不一致） -
assert.assertions缺少"categories:accessibility"显式声明：只写"categories:performance"不会自动带出可访问性校验，Lighthouse CI 不做隐式推导 -
minScore写成整数：配置里写{"minScore": 90}是无效的，必须是小数{"minScore": 0.9}，否则该断言静默忽略
a11y-checker 在构建流程中怎么嵌入才不拖慢打包
它是纯静态 AST 分析，不依赖浏览器环境，但默认会遍历所有 HTML 文件，包括 node_modules 和构建产物，导致误报和性能浪费。
- 只检查源码目录：CLI 调用时限定路径，例如
npx a11y-checker src/pages/*.html，避免扫dist/或public/ - 排除框架模板干扰：Vue 的
v-for生成的重复 ID、React 的key属性会被误判为id-duplication，在配置里加ignore: ["id-duplication"]更合理 - 不建议放
prebuild钩子：它不校验 JS 行为（如焦点管理、键盘事件），放在postbuild后检查最终 HTML 更贴近真实交付物
WAVE 插件报告里 “Contrast Error” 点开却找不到对应元素
WAVE 会在 DOM 渲染后计算颜色值，但某些 CSS 变量、@media 条件或 Shadow DOM 内部样式会导致它定位失败。
- 先切到 Chrome DevTools 的 Elements 面板，右键目标文本 →
Copyp outerHTML，粘贴到新 HTML 文件里单独测，排除 JS 干扰 - 检查是否用了 CSS 自定义属性（如
--text-color: #333），WAVE 无法解析变量值，需手动替换成实际色值再验证 - Shadow DOM 内的元素需在 DevTools 里勾选
Show user agent shadow DOM，否则 WAVE 扫描不到内部节点
真正难的不是跑出报告，而是判断哪类问题必须阻断发布、哪类可以标记为 tech debt。比如 alt 缺失和 lang 属性缺失都算 error，但前者影响屏幕阅读器基础功能，后者直接影响 SEO 和字符解析——修复优先级完全不同。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
