axe-core 更适合作为 CI 中的可访问性断言核心，因其是断言型工具，可直接抛错中断构建、支持细粒度规则开关、适配多种 DOM 环境、错误定位精准、易于集成测试框架；而 Lighthouse 是报告型工具，需额外配置、资源开销大、不可裁剪且难以对齐现有测试。
为什么 axe-core 比 Lighthouse 更适合作为 CI 中的可访问性断言核心
Lighthouse 的 lhci autorun 默认不因可访问性低分失败，而 axe-core 可直接在测试流程中抛出错误并中断执行——它天生是“断言型”工具，不是报告型。你在 CI 里跑 axe.run() 后检查 results.violations.length > 0，就能立刻让构建失败，无需额外配 assertions 规则或上传服务器。
- axe-core 支持细粒度规则开关（如只检测
"wcag2aa"），Lighthouse 则固定维度、不可裁剪 - axe-core 可注入任意 DOM 环境（JSDOM、Playwright page、真实浏览器），Lighthouse 必须启动 Chromium 实例，CI 资源开销大
- axe-core 错误定位精准到
violation.nodes[0].target（CSS 选择器路径），Lighthouse 报告里常只给模糊的“element with role=button” - 若用 Jest/Vitest 做单元/集成测试，
axe-core可直接 import 并 assert；Lighthouse 需另起进程，难以与现有测试套件对齐
如何在 Playwright 测试中嵌入 axe-core 自动化断言
别再手写 page.accessibility.snapshot() 这种弱校验——它只返回基础属性，不覆盖 WCAG 规则。真正在 E2E 中做可访问性守门，得用 axe-core 注入页面上下文执行完整扫描。
- 安装：
npm install axe-core，然后在 Playwright test 文件里import axe from 'axe-core' - 注入脚本：
await page.addScriptTag({ path: require.resolve('axe-core') })（确保 axe 在页面全局可用） - 执行扫描：
const results = await page.evaluate(() => (window as any).axe.run()) - 断言处理：
expect(results.violations).toHaveLength(0)，失败时打印results.violations.map(v => v.help)定位问题 - 注意：React/Vue 应用需等 hydration 完成再扫，加
await page.waitForFunction(() => document.querySelector('#root')?.children.length > 0)
CI 环境下 axe-core 扫描失真的三个关键原因
本地跑分全绿，CI 里突然报一堆 "color-contrast" 或 "heading-order" 错误？大概率不是代码退化，而是环境差异导致 axe 看到的 DOM 和你本地不一样。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
document.documentElement样式未加载完成：CI 中 CSS 可能异步加载或被 block，axe 扫描时计算 color contrast 用的是默认浏览器颜色，加await page.waitForLoadState('networkidle')再扫 - 字体未就绪：axe 依赖
getComputedStyle获取字号/颜色，但自定义字体可能未渲染完成，加await page.waitForFunction(() => document.fonts.check('1em "Inter"')) - Shadow DOM 未暴露：若组件用 Lit 或 Stencil 封装，axe 默认不进 shadowRoot，需传配置
{ runOnly: { type: 'tag', values: ['wcag2aa'] }, shadowDom: true }
eslint-plugin-jsx-a11y 不能替代运行时 axe 扫描
eslint-plugin-jsx-a11y 只检查 JSX 源码结构，比如 <img> 缺 alt、<button> 缺 type，但它完全不知道最终渲染出的 DOM 是什么样子。
立即学习“前端免费学习笔记（深入）”；
- 它无法捕获服务端渲染后丢失的
aria-label、JS 动态插入的无语义 div、CSSdisplay: none但仍在 DOM 中的元素 - 它不校验颜色对比度、焦点顺序、屏幕阅读器实际朗读内容（比如
aria-live区域是否触发） - 它对第三方库组件（如 MUI、Ant Design）基本无效——这些组件内部逻辑不在你的 JSX 里
- 真正可靠的防线是：开发时用 ESLint 提前拦截明显错误，CI 中用 axe-core 对真实 DOM 做终验
axe-core 不是“锦上添花”，它是最后一道防线。只要 DOM 渲染结果有偏差，哪怕只差一个 tabIndex="-1" 或一个没关闭的 aria-hidden="true" 容器，就会漏检。别信“我写了语义标签就 OK”——可访问性只存在于渲染后的 DOM 树里，不是源码里。
