浏览器自动修复html错误会掩盖真实结构问题，导致dom与源码不一致，引发js选择器失效、css样式异常及无障碍树断裂；需通过elements面板、edit as html跳变测试、document.queryselectorall验证及读屏工具听读顺序来确认结构正确性。
浏览器自动修复 HTML 错误会掩盖真实结构问题
HTML 不是“写完就能跑”的标记语言，浏览器遇到非法嵌套或未闭合标签时，会强行重排 DOM 树——你写的 <p></p>
<div></div>
<p></p>
<div></div>，导致 querySelector('.wrapper > div') 拿不到预期节点。这种“看起来正常”的假象，是后期 JS 绑定失效、CSS 选择器失效、无障碍树断裂的根源。
常见触发场景包括：<p></p> 内部塞 <div>、<code><ul></ul> 里插 <p></p> 或 <section></section>、<main></main> 被包在 <section></section> 里。DevTools 的 Elements 面板显示的 DOM，已经是浏览器“抢救”后的结果，不是你写的源码。
- 用右键 → “Edit as HTML” 在 DevTools 中删一个字符再回车，观察结构是否跳变——跳变即说明原始 HTML 已被修正
- 运行
document.querySelectorAll('main')检查是否真有且仅有一个<main></main> - 打开 VoiceOver 或 NVDA，听读顺序是否与视觉流一致；不一致往往源于语义标签缺失或嵌套错乱
语义化标签不是美化，而是 DOM 解析前提
搜索引擎和辅助技术不解析 class 名，只依赖原生标签语义。把 <div class="header"></div> 改成 <header></header>，不是为了“好看”，而是让 Accessibility Tree 正确生成导航节点，让爬虫把该区域识别为页首而非普通容器。
关键硬性约束必须遵守：
-
<main></main>必须且只能出现一次，且不能是<article></article>、<section></section>、<aside></aside>的子元素 -
<nav></nav>只包裹真实导航链接，广告位、社交图标、登录入口别塞进去 -
<ul></ul>和<ol></ol>的直接子节点只能是<li>；中间插<div> 或 <code><p></p>会导致querySelectorAll('li')漏项，屏幕阅读器跳过整条 -
<h1></h1>应出现在<main></main>内部，而非<header></header>的 logo 区域——否则主体内容权重被稀释 缺失或位置不对：放在 <code>后面？直接触发怪异模式，Flex/Grid 行为异常-
<meta charset="UTF-8">没放开头前三位：旧版 Safari 和 IE 会乱码，且htmlhint的meta-charset-require规则会报错 - 标签名大写：如
<div>、<code><img>—— W3C 规范要求小写，虽不影响渲染，但和 ESLint/TypeScript 工程链路冲突，CI 流水线可能直接失败建议在 VS Code 中装 HTMLHint 插件，开启
doctype-first、meta-charset-require、tagname-lowercase这三条规则，保存即提示。在线 IDE 重构时最容易踩的预览陷阱
CodePen、Glitch 这类平台实时预览很爽，但它们默认加载的是“修复后”的 DOM，不是你正在编辑的源码。你改完
，预览窗口看着没问题，可一导出 HTML 交给后端或部署到 Nginx，就发现 JS 找不到父容器了。<p></p> <div></div>- 在预览窗口右键 → “View Page Source”，看实际输出的 HTML 是否和编辑区一致（很多在线 IDE 的 Source 是渲染后版本）
- 用
fetch('/index.html').then(r => r.text()).then(console.log)在控制台打印原始 HTML 字符串，比对嵌套层级 - 重构过程中禁用所有 CSS，纯 HTML 结构下检查语义标签是否仍能表达内容逻辑——如果去掉样式后完全看不出哪是导航、哪是正文，说明语义还没立住
真正难的不是把
div换成section，而是确认换完之后，DOM 层级没被浏览器悄悄打散，JS 选择器依然有效，无障碍设备仍能按正确顺序读出标题和段落。
HTMLHint 能抓到但人容易忽略的三类低级错误
本地跑 htmlhint 很快，但真正卡住重构进度的，往往是那些“浏览器能容错、工具默认不报、人眼扫一遍就跳过”的细节。
