html解析器不解析注释内的脚本，所有内容（含、fetch()等）均被当作文本丢弃，不建dom节点、不执行、不校验语法；常见错误为uncaught syntaxerror: unexpected token '。
HTML解析器根本不会“识别”注释里的脚本
浏览器解析器看到<!--，就进入“跳过模式”，一直扫描直到遇到-->为止。中间所有内容——包括<script></script>、fetch()、<img onerror="alert(1)">——全被当作文本丢弃，不建节点、不执行、不校验语法。它不是“识别后阻断”，而是压根不纳入解析流程。
常见错误现象：Uncaught SyntaxError: Unexpected token '通常不是因为注释里有脚本，而是你误把<code><!--写进了 JS 字符串或innerHTML赋值中，导致 HTML 解析器在不该出现注释的地方遇到了<!开头的非法标记。
为什么<!-- <script>alert(1)</script> -->看似安全却不可靠
这段代码确实不会触发alert(1)，但它的“安全”完全依赖于注释边界未被破坏。一旦有用户输入参与拼接，比如后端模板生成时插入了未转义的-->，整个注释就会提前闭合。
- 攻击者输入：
userInput = "--><script>steal()</script><!--" - 拼接后变成：
<!-- <div>hello <!--+--><script>steal()</script><!--+--> - 结果：第一个
-->结束注释，后续<script></script>被正常解析执行
这不是解析器“失效”，而是注释机制本身不具备上下文感知能力——它只认字面量<!--和-->，不区分来源。
服务端注释 vs 客户端注释：执行时机决定风险等级
服务端模板（如 EJS、Django）里的<!-- <%= user.input %> -->危险在于：模板引擎先求值，再把结果塞进注释块。如果user.input是--><script>...</script>，那注入已经发生在 HTML 生成之前。
而纯静态 HTML 中的<!-- ... -->无此问题，因为没执行环节。但凡涉及动态插值，就必须在插值前完成编码或过滤，不能指望注释兜底。
- 错误做法：用注释包裹未净化的变量输出
- 正确做法：对
user.input调用escapeHtml()后再插入，或用模板引擎的自动转义机制 - 构建工具（如 Webpack）默认不保留注释，若需调试用，得显式配置
minimizerOptions保留<!-- DEBUG -->类标记
别把注释当 XSS 防御手段
HTML 注释对 XSS 零防护能力。CSP、DOMPurify、输出编码才是正解。注释唯一能防住的，只有你自己手抖写错的那几行测试代码。
真正容易被忽略的是：你在<script></script>标签里写<!--和-->，既无必要又增加出错概率。现代 JS 不需要这种兼容性写法，删掉更干净。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
