W3C Validator 是最权威的HTML标准验证工具，可精准定位语法错误；Chrome DevTools 辅助发现DOM结构断裂；axe 插件专查语义缺陷；html-validate 支持CI/CD自动检查。
用 W3C Validator 检查 HTML 是否符合标准
W3C Markup Validation Service 是最权威的免费工具，它不只报错，还明确指出哪一行、哪个标签违反了 HTML 规范。很多“看着能渲染”的页面其实存在隐性结构问题，比如嵌套错误或缺失 根节点，这类问题在旧版 IE 或屏幕阅读器中容易暴露。
- 直接粘贴代码时，确保包含完整的
和 <code>开闭标签，否则会误报“文档无根元素” - 验证远程 URL 时，工具抓取的是服务器返回的原始 HTML，不是浏览器渲染后的 DOM —— 所以 JS 动态插入的内容不会被检查
- 遇到
Bad value X for attribute Y类错误，常见于自定义属性没加data-前缀，比如写role="button"是合法的，但status="loading"必须改成data-status="loading"
Chrome DevTools 里快速查看 DOM 树结构是否合理
浏览器开发者工具不是验证器，但它能立刻暴露结构断裂点，比如意外的自动闭合、父容器丢失、或 <div> 被塞进 <code><p></p> 这类非法嵌套（Chrome 会悄悄把后者拆开，导致 DOM 和源码不一致）。
- 右键「检查」后，在 Elements 面板里观察节点缩进是否连贯；如果某层突然左对齐、没缩进，大概率是上层标签没闭合或被浏览器纠错了
- 选中一个元素，按
Ctrl+Shift+C（Win）或Cmd+Shift+C（Mac）再点页面任意位置，能跳转到对应 DOM 节点 —— 这比手动滚动找更快 - 注意看右下角显示的「Rendered width/height」和「Computed」里的
display值：如果本该是块级的<section></section>显示为inline，说明可能被 CSS 强制改了，但结构本身没问题；而如果节点根本没出现在 Elements 里，那才是结构被浏览器丢弃了
用 axe 浏览器插件查语义结构缺陷
W3C 验证器不管语义对不对，axe 则专注检查 ARIA 标签、标题层级、<main></main>/<nav></nav> 等地标元素是否缺失或滥用 —— 这些不影响渲染，但破坏可访问性和 SEO。
- 安装 axe DevTools 插件后，点「Analyze」，重点看「Structure」和「ARIA」两类问题；例如提示
Heading order must increase by one，意味着从<h2></h2>直接跳到<h4></h4>，中间缺了<h3></h3> - 它会标出具体哪行 HTML，但不会告诉你怎么修；比如报
Document must have one main landmark，你要确认是否漏了<main></main>，或者误把两个<main></main>并列写了（HTML 规范只允许一个） - axe 不检查纯样式问题（如颜色对比度），也不替代 W3C 验证；两者配合用才完整：W3C 看“语法”，axe 看“意思”
本地用 html-validate 做 CI/CD 自动检查
手工验证容易漏，尤其多人协作时。html-validate 是 Node.js 工具，能集成进 Git Hook 或 CI 流程，强制提交前过一遍规则。
立即学习“前端免费学习笔记（深入）”；
- 安装后运行
npx html-validate src/index.html，默认启用较严格的推荐规则；想放宽可配.htmlvalidate.json，比如关掉require-sri（子资源完整性）这类非结构相关项 - 常见误报来自模板语法，比如 Vue 的
<template></template>或 Nunjucks 的{% extends %}；需在配置里用ignore字段排除匹配模式，或改用html-validate-loader配合 Webpack - 它不解析 JS，所以
document.write()生成的 HTML 不会被检查；动态内容得靠端到端测试覆盖，不能只依赖静态扫描
结构验证真正的难点不在工具使用，而在于分清「浏览器容错行为」和「规范要求」——比如 Chrome 允许 <div> 直接放在 <code><table> 外，但规范要求表格内容必须包裹在 <code><tbody> 里。工具报错时，先别急着删代码，查清楚是该修 HTML，还是该接受浏览器的纠错逻辑。</tbody>
