HTML注释中禁止出现“--”及“-->”，引号和尖括号无需转义；若需嵌入结构化数据，应使用替代。
HTML 注释里不能出现 -- 和结尾的 --> 组合
HTML 注释语法是 ，但规范明确禁止在注释内容中出现连续两个短横线 --，也不允许注释以 --> 提前结束。这意味着哪怕你只是想写 foo--bar 或 test-->，浏览器解析器会直接报错或截断注释——不是渲染问题，是解析失败。
常见错误现象：
– 页面部分不渲染，控制台无报错但源码显示注释提前终止
– DevTools 中看到注释被截成两段，后半内容变成文本节点
– 使用 innerHTML 动态插入含 -- 的注释字符串时抛出 DOMException
- 不要试图用 HTML 实体替代短横线（如
-），注释内部不解析实体 - 如果必须保留双短横语义，改用其他符号代替，例如
foo — bar（en dash）或foo - - bar（加空格） - 注释末尾绝对不要写
-->，哪怕它看起来“只是字符串”，解析器会无条件视为结束符
引号和尖括号在 HTML 注释里不需要转义
HTML 注释属于 CDATA 类型， 之间的所有字符（除 -- 和结尾 --> 外）原样保留，不参与 HTML 标签解析，因此 "、'、、> 全部无需转义。
使用场景：
– 写调试说明，比如
– 注释掉一段含内联 JS 或模板语法的代码块，如
立即学习“前端免费学习笔记（深入）”；
- 上面两个例子都能安全存在，浏览器不会尝试解析其中的引号或标签
- 但注意：如果注释被 JavaScript 动态读取（如
document.body.innerHTML），再用JSON.parse()解析注释里的 JSON，那里面的引号仍需符合 JSON 语法（即双引号包裹、单引号不行） - 尖括号在注释里不会触发标签匹配，所以
或
真正需要转义的是注释内容被 JS / CSS / 服务端二次处理时
注释本身对浏览器是安全的，但如果你把注释当“数据容器”用，后续由其他语言或工具提取处理，那就得按对应上下文规则转义。
典型场景：
– 后端模板（如 Jinja2、Twig）把注释当变量注入，结果 " 被当成模板字符串边界
– JS 脚本用正则从 document.body.innerHTML 提取注释内容，然后 eval() 执行，此时 " 和 \ 就得按 JS 字符串规则转义
– 构建工具（如 Webpack）扫描注释提取 i18n 字符串，遇到未闭合引号可能中断提取
- 若 JS 中动态生成注释字符串，确保双引号用反斜杠转义：
const comment = ``;
- 若用正则提取注释内容，别用
//g这种简单模式——它无法识别嵌套或非法--，建议用 DOMParser 或专用 HTML 解析器 - 服务端输出注释前，确认模板引擎是否开启自动转义；例如 Django 模板中
{% autoescape on %}下，{{ comment_text }}会把变成zuojiankuohaophpcn，破坏注释结构
替代方案：用
如果目标是嵌入结构化数据（比如配置、元信息），HTML 注释本质是 hack，既难维护又易出错。现代做法是用
JS 端读取：
const configEl = document.getElementById('page-config');
const config = JSON.parse(configEl.textContent);
- 比注释更语义化，支持 IDE 自动补全和 JSON 校验
- 避免所有
--、引号、尖括号相关陷阱 - 注意：不要给该 script 加
defer或async，否则可能在 JS 执行前被移除（某些优化插件会删“无执行逻辑”的 script）
注释不是数据容器，只是给人看的标记。一旦开始往里面塞 JSON、XML、甚至带引号的路径，就等于在解析器边缘反复试探——表面能过，实际随时可能因一个没注意的 -- 或模板层多一次转义而崩掉。
