W3C Validator 报“Element img is not closed”是因<img></img>非法嵌套，违反HTML5空元素规范，导致DOM解析错乱；合法写法仅<img src="x" alt="y">，而<img />属XHTML风格，非标准但容错。
W3C Validator 报 “Element img is not closed” 是什么问题
这不是浏览器警告，是 HTML5 规范级错误。<img> 是 void element（空元素），合法写法只有 <-img src="x" alt="y">；<img src="x" alt="y" /> 属 XHTML 风格，在 HTML5 中容错但非标准；而 <img></img> 是非法嵌套，会导致后续所有标签层级偏移——浏览器会立刻中断解析并尝试修复，DOM 已不是你写的那样。
这类问题在 JS 动态插入 HTML 时尤其隐蔽：比如模板字符串里拼错了，innerHTML = "<img src='a'></img>"，执行后 DOM 结构就乱了，但控制台不报错。
-
html-validate配置"html-validate/no-self-closing": "error"可提前拦截<img />类写法（注意：它不拦<img></img>，那是更严重的嵌套错误） - 编辑器插件（如 Auto Close Tag）无法识别
<img>是否该闭合，容易盲目补</img> - 真正要防的是
<div><p>text</div>这类漏闭 + 错嵌，它不会触发no-self-closing，但会让<p>被意外包裹进<div>后续所有内容
为什么 htmlhint 的 tag-pair 规则不能替代浏览器解析验证
tag-pair 能精准定位 <div><p>text</div> 这类“有开无闭”或“闭多于开”的行号列号，但它只做静态文本匹配，不模拟浏览器的插入模式和开放元素栈行为。
也就是说：tag-pair 会报错 <div><p>text</div>，但它不会告诉你：浏览器实际生成的 DOM 是 <div><p>text</p></div>（因为 <p> 遇到块级兄弟自动隐式闭合），也不会预警 <nav><header>content</nav> 这种非法嵌套导致 <header> 被吞进 <nav> 的语义污染风险。
立即学习“前端免费学习笔记（深入）”；
- 它对自闭合标签（
<img>、<input>）完全不校验是否写了/>，只关心“成对性” - 混用 Vue/JSX 模板时，
tag-pair常误报片段（如<template>内未闭合的<div>），需手动关掉："tag-pair": false - 真正需要交叉验证：先用
htmlhint扫文本级错误，再用 W3C Validator 或jsdom加载后检查实际生成的 DOM 结构
CI/CD 中如何让 HTML 自愈重构真正落地
所谓“自愈”，不是靠 AI 猜你本意，而是用确定性工具链把容错逻辑显性化、可审计、可回滚。推荐三步流水线：htmlhint → tidy-html5 → html-validate，其中 tidy-html5 是关键——它比编辑器更懂 HTML 嵌套逻辑，能按标准规则重排结构，而不是机械补 </div>。
-
tidy-html5 --show-body-only yes --wrap 0 --indent auto --tidy-mark no：关闭冗余标记，保留原始缩进语义 - 配置
tidy-html5的drop-empty-elements和drop-empty-*选项，避免空标签干扰结构 - 不要依赖 Prettier 校验结构——
htmlWhitespaceSensitivity: 'strict'只管空格，不管闭合
修复后页面仍错位？源头常不在你改的那一行
一个未闭合的 <div> 可能导致后续几百行 HTML 全部被错误包裹。修复时容易陷入局部思维：
- 看到
<footer>跑进<header>，第一反应是去修<header>末尾，其实问题可能出在前面第 3 个<section></section>漏了 - 用
document.querySelectorAll('*').length查 DOM 节点数，如果远超预期（比如几万），说明嵌套已失控，源头往往藏在前 20 行 - 动态插入内容（如
v-html、innerHTML）时，传入的内容若含未闭合标签，框架不校验，直接交由浏览器解析——错位根源可能在 API 返回的 HTML 片段里
