html注释不参与dom构建但作为comment节点存在，用于说明结构意图而非替代语义标签；必须用书写，禁含--或嵌套，否则导致解析截断、dom错乱。
HTML 注释本身不参与文档结构构建，也不会改变 DOM 树的层级或语义，但它对开发者理解文档结构至关重要——它不是结构的一部分，却是结构的“说明书”。
注释不能替代语义化标签，但能暴露结构意图
浏览器解析时会把 <!-- --> 当作 Comment 节点加入 DOM，但它不会影响布局、可访问性或 SEO。也就是说，加了 <!-- 导航栏开始 --> 并不会让 <nav></nav> 更“像导航栏”，也不会修复缺失的语义。真正起作用的是标签本身。
但现实是：很多 HTML 文件结构复杂、嵌套深、模块多，光靠标签名和 class 很难一眼看出某段 <div> 是轮播容器、还是广告位、或是临时插入的 A/B 测试区块。这时候注释就是唯一能承载“设计意图”的载体。<ul>
<li>常见错误现象：接手项目时看到 <code><div class="wrap"><div class="inner">...</div></div>，完全无法判断这个嵌套是为样式隔离、JS 操作预留，还是历史遗留冗余
<!-- user profile section --> 比 <!-- div here --> 有效十倍嵌套注释会导致解析失败，必须避免
HTML 标准明确禁止在 <!-- 和 --> 之间再出现 --，哪怕只是两个连续的短横线（如 “--end” 或 “data--v1”）。一旦出现，浏览器会提前截断注释，后续内容可能被误解析为 HTML 或文本，造成布局错乱或脚本执行异常。
- 典型错误：写
<!-- header -- v1.2 -->，实际会被解析成<!-- header --+v1.2 -->，后半部分变成可见文本 - 安全写法：用单个短横代替，如
<!-- header - v1.2 -->；或换行分隔，如<!-- header --><!-- v1.2 --> - 调试建议：Chrome DevTools 的 Elements 面板里，Comment 节点会显示为灰色文字；若发现注释突然中断或后面内容变红/错位，第一反应应检查是否混入了
--
注释位置影响可维护性，而非渲染结果
理论上 <!-- --> 可以放在任何地方：开头、标签内、属性值中间（不行）、甚至 <script></script> 块里（需注意 JS 解析器行为）。但放错位置会让协作成本飙升。
- 推荐位置：模块起始前一行（
<!-- 侧边栏开始 -->），而不是塞在<aside></aside>开始标签后面 - 易踩坑：把注释写在
内但紧贴结束标签，容易让人误以为属于 head 内容 - 性能影响：注释不触发重排重绘，但过长的注释（比如整段 JSON 或 base64 图片）会增大 HTML 体积，拖慢首次字节传输（TTFB 后的下载阶段），尤其对移动端弱网用户敏感
真正容易被忽略的，不是“要不要写注释”，而是“注释写给谁看”——如果只写给自己看，几个月后你也需要重新破译；如果写给团队看，就得统一标记风格、禁用规则和更新机制。一个没被更新的 <!-- TODO: 后端接口已上线，此处可删 --> 比没写注释更危险。
