HTML解析器对注释的处理是“跳过”而非“忽略”，需扫描识别并丢弃，消耗CPU和栈空间；服务端注释更安全；应避免在script/style内写HTML注释，并警惕伪装成注释的数据块。
HTML解析器对注释的处理是“跳过”而非“忽略”
浏览器HTML解析器在构建DOM树前，必须扫描并识别所有<!--到-->之间的内容，然后丢弃。这个过程不是零开销：解析器要维护状态机、匹配起始/结束标记、处理嵌套（虽然HTML注释不支持嵌套，但需校验）、跳过内部字符。它不把注释转成节点，但会消耗CPU周期和少量栈空间。
实测表明，单个<!--块内含100KB纯文本时，Chrome HTML解析阶段耗时增加约0.8–1.2ms（在Performance面板中可捕获）。这不是瓶颈，但当注释块数量多、体积大、且出现在首屏HTML头部时，会轻微拉长首字节（TTFB）后的解析延迟。
注释体积超5%时内存压力开始可见
关键阈值不在绝对大小，而在注释占整个HTML响应体的比例。当未压缩HTML中注释占比超过5%，且文件总大小超200KB时，V8引擎在解析初期的字符串暂存区（StringTable）和临时缓冲区分配量会上升——尤其在SSR模板中动态注入大量<!-- DEBUG: ... -->时，这些字符串可能被JS上下文意外引用，导致无法及时GC。
验证方法很简单：
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 用
curl -sI https://yoursite.com/page.html | grep 'content-length'查原始响应头 - 用
wc -c < page.html得文件总字节数 - 用
grep -o '<!--.*?-->' page.html | wc -c粗略估算注释总字节数（注意：该正则不匹配跨行注释）
若注释字节数 ÷ 总字节数 > 0.05，就值得干预。
服务端注释比客户端注释更安全
像<%-- this won't reach browser --%>（JSP）、{# this is Jinja2 #}或@* ASP.NET Razor *@这类服务端注释，在HTML生成阶段就被移除，完全不进HTTP响应体。它们不影响传输体积、不参与浏览器解析、也不占用客户端内存。
而<!--是客户端注释，哪怕只写一行，也会走完整网络链路和解析流程。生产环境应做到：
- 构建工具（如html-minifier-terser）默认开启
removeComments: true - 调试注释统一加前缀，如
<!-- DEV: ... -->，上线前用sed -i '/<!-- DEV:/,/-->/d' *.html批量清除 - 禁止在
<script>或<style>标签内写HTML注释（无效，且可能干扰CSS/JS解析器）
真正危险的是“伪装成注释”的数据块
最常被忽略的坑，是把Base64图片、JSON Schema、或整段废弃HTML代码塞进
