真正有效的HTML质量可视化必须基于真实DOM状态而非静态扫描。需用document.querySelectorAll等API提取解析后指标，结合Performance API、MutationObserver和console代理捕获动态劣化，并按工程责任归属（如CMS、组件库、业务代码）归因，使问题可定位、可归因。
单纯堆砌监控指标做 HTML 大屏，解决不了代码质量的真实问题。真正有效的可视化，必须从 HTML 结构本身出发，把 document 的实际解析状态、关键标签合规性、资源加载链路和运行时异常聚合起来，才能让“质量”可定位、可归因。
如何从 HTML 源码中提取可监控的质量信号
浏览器不会直接暴露“HTML 是否规范”的布尔值，得靠解析后的真实 DOM 状态反推。比如 document.querySelectorAll('img:not([alt])') 比静态扫描更可靠——它反映的是最终渲染时缺失 alt 的真实图片数；document.querySelectorAll('a[href^="javascript:"]') 能抓到绕过 CSP 的危险跳转，而 ESLint 插件根本看不到这些内联行为。
- 优先用
document.querySelectorAll而非正则匹配 HTML 字符串：后者无法处理模板字符串、注释干扰、服务端渲染的动态片段 - 对
form元素检查novalidate属性是否被误加：它会绕过原生校验，但 DOM API 可直接读取form.noValidate - 统计
iframe的src协议：用new URL(iframe.src).protocol判断是否存在http://混合内容，比字符串截取更健壮
为什么不能只依赖 Lighthouse 或 axe-core 的快照结果
Lighthouse 运行在干净的无痕环境，测不出用户真实场景下的 DOM 动态污染；axe-core 默认只检测可见元素，而 aria-hidden="true" 包裹的无效结构仍可能被屏幕阅读器意外聚焦。大屏要展示的是“线上每秒都在发生的劣化”，不是某次审计的静态分数。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 把
performance.getEntriesByType('navigation')和performance.getEntriesByType('resource')作为基础数据源：它们能实时反映 HTML 解析耗时、子资源阻塞情况 - 监听
DOMSubtreeModified已废弃，改用MutationObserver观察document.body下新增的script或style标签——这是第三方 SDK 注入脚本的典型痕迹 - 对
console.error做代理捕获时，过滤掉ResizeObserver loop limit exceeded这类已知良性错误，避免噪声淹没真实 JS 执行崩溃
大屏上 HTML 质量指标的可视化陷阱
显示“HTML 错误数：127”毫无意义。用户需要知道这 127 个错误里，有多少来自 CMS 输出模板（可推动后端修复），多少来自前端组件库（需升级版本），多少是用户粘贴富文本导致（需前端拦截）。
立即学习“前端免费学习笔记（深入）”；
- 用
document.currentScript?.src定位报错脚本来源，再结合stack中的文件路径做正则分组：匹配/node_modules\/.*?\/归为依赖问题，匹配/src\/pages\/归为业务代码 - 对
meta[name="viewport"]缺失的页面，不只标红，还要叠加显示当前设备window.innerWidth和document.documentElement.clientWidth的差值——差值越大，响应式失效越严重 - 把
document.querySelectorAll('[id]')中重复id的数量，和对应元素的closest('[data-component]')属性关联，就能定位到具体哪个 React/Vue 组件在循环渲染时没正确生成唯一 key
真正的难点不在采集，而在把 DOM 的碎片化状态，映射回前端工程的协作边界。比如一个 aria-label 缺失，可能是设计师没给标注规范、产品经理没写需求、开发没配自动化检查、测试没覆盖无障碍用例——大屏数字背后，得让人一眼看出该拉谁进钉钉群。
