html注释不影响可访问性但显著提升维护效率，因其被浏览器完全忽略、不参与语义计算，仅服务于开发者；未闭合、含--、配对缺失或未清理的todo/fixme注释会破坏解析、降低定位效率、暴露隐患并增加协作成本。
规范化HTML注释不能提升可访问性（a11y），但能显著降低工程维护成本——尤其在多人协作、长期迭代和跨团队交接场景下。
为什么注释不影响可访问性，但影响维护效率
浏览器解析时会把 <!-- ... --> 完全忽略，既不暴露给屏幕阅读器，也不参与 DOM 树的语义计算。所以加再多注释，aria-label 不写还是不写，alt 空着还是空着。它解决不了 WCAG 合规问题。
但它直接影响人：新成员打开一个 2000 行的 index.html，靠 Ctrl+F 搜 <!-- Header Start --> 能 3 秒定位区块；搜 <header></header> 可能要翻 5 分钟，还容易点错闭合标签。
- 注释是“人的索引”，不是“机器的语义”
- 未配对的
<!-- Main Start -->/<!-- Main End -->会导致折叠功能失效，IDE 无法收起整个模块 - 用
<!-- TODO: 补充 aria-describedby -->比藏在脑里靠谱，也比 Slack 里发一条消息更不易丢失
哪些注释格式最容易引发解析错误
看似安全的写法，实际可能让整段 HTML 消失——浏览器遇到第一个 -- 就提前结束注释，后面所有内容都被当注释吞掉。
- 绝对禁止在注释正文里出现连续两个短横线：
<!-- 这里是--临时方案 -->→ 错误 - 推荐用等号或空格替代视觉分隔：
<!-- ======= Banner Section ======= --> - 禁用编辑器自动补全
-->的功能，改用 snippet 插入完整配对标记 - CI 阶段用
eslint-plugin-html检查no-html-comment-in-comment和no-html-dash-in-comment规则
上线前必须清理的三类注释
构建流程中不移除它们，等于把开发线索直接打包发给用户。
-
<!-- FIXME: Safari 下 flex gap 不生效 -->→ 暴露兼容性短板，竞品可针对性绕过 -
<!-- DEBUG: data-user-id="12345" -->→ 泄露内部 ID 结构或调试逻辑 -
<!-- TODO: 接入权限校验 -->→ 生产环境留着，等于公开承认功能缺失
保留版权注释（如 <!-- © 2026 MyCorp. All rights reserved. --> ）和条件注释（如 <!--[if IE]>）需显式白名单，不能一并 removeComments: true。
团队落地时最常被忽略的细节
不是“要不要写注释”，而是“谁来保证它一直有效”。真实项目里，90% 的注释腐化发生在无人校验的合并后。
- 注释配对必须纳入 Code Review Checklist，PR 中出现
<!-- Footer Start -->但没<!-- Footer End -->直接拒收 - 用 IDE 的代码折叠验证：展开/收起应严格对应起止标记，否则说明嵌套错位或漏写
- 禁止用中文标点如《》、【】、—— 替代英文破折号，某些旧版构建工具会因编码问题截断注释
注释一旦写进代码，就和 class 名一样需要生命周期管理——没人更新的注释，比没有更危险。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
