HTML注释中写JavaScript会出问题，尤其在老版IE或构建工具中可能被误解析导致语法错误或白屏；注释不支持嵌套，嵌套会导致解析中断；服务端模板中混用HTML注释与模板语法存在安全风险。
HTML 注释里写了 JavaScript 会出问题吗
会，而且很隐蔽。浏览器解析 HTML 时，<!-- 和 --> 之间的内容本该被完全忽略，但如果你在里面写 console.log() 或 if (x) { ... }，某些老版本浏览器（比如 IE8–IE10）或某些构建工具（如 Webpack 的 HTML 插件）可能误解析——尤其当注释跨行、含 <script> 标签或引号不闭合时。
常见错误现象：Uncaught SyntaxError: Unexpected token < 或页面白屏，但控制台没报错位置；或者构建后注释里的 JS 被当成字符串拼进 HTML，导致运行时执行了不该执行的代码。
- 别在
<!-- -->里写任何可执行逻辑，哪怕只是let x = 1; - 调试用的临时代码，改用
//放在<script>块内，或直接删掉 - 如果必须保留说明性“伪代码”，确保它不包含
<、>、"、'等可能触发解析歧义的字符
HTML 注释嵌套导致解析中断
HTML 不支持注释嵌套，<!-- outer <!-- inner --> outer end --> 这种写法会让浏览器在第一个 --> 就结束注释，后面的内容变成裸露的 HTML 文本，可能被渲染、被 JS 读取，甚至破坏 DOM 结构。
使用场景：多人协作改版时，有人想“暂时屏蔽一段带注释的代码”，随手套了一层 <!--，结果埋下隐患。
立即学习“前端免费学习笔记（深入）”；
- 检查所有
<!--是否都有且仅有一个对应-->，用编辑器的括号高亮功能快速定位 - VS Code 中可安装插件
Auto Close Tag，但它对 HTML 注释无效——得靠人工扫或正则搜索：<!--[\s\S]*?-->（注意非贪婪） - 构建阶段可用
html-validate工具检测未闭合注释，配置规则"no-unclosed-comment"
服务器端模板里混用 HTML 注释和模板语法
像 EJS、Nunjucks、Django 模板中，<!-- {{ variable }} --> 看似安全，其实危险：模板引擎先执行 {{ variable }} 渲染，再把结果塞进注释；如果 variable 是用户输入，就可能注入恶意内容，或让注释提前截断。
性能影响不大，但安全性和可维护性极差——你根本不知道注释里最终写了什么。
- 服务端变量要注释，改用模板引擎原生注释语法，比如 EJS 的
<%# this is safe %>，Nunjucks 的{# this is safe #} - 绝对不要把
{{、{%、放在 <code><!--和-->之间 - CI 流程中加一条检查：禁止
<!--.*\{\{.*\}\}.*-->这类正则匹配
HTML 注释被压缩工具意外删除
很多构建工具（如 html-minifier、webpack-html-plugin 默认配置）会直接删掉所有 <!-- 注释，包括你用来标记区块用途的 <!-- header start -->。上线后排查问题时发现“注释没了”，其实是构建阶段被抹掉了。
兼容性影响：开发环境能看到，生产环境看不到，导致团队新人无法快速理解结构。
- 若需保留特定注释，
html-minifier加参数--keep-comments，或用正则白名单：ignoreCustomComments: [/^!/]（保留<!--! keep -->这类） - 更稳妥的做法：用 class 名替代注释，比如
<div class="section-header-start">，语义清晰还不怕被删 - 检查
vue-cli或create-react-app的默认配置，它们的html-webpack-plugin版本不同，对注释处理逻辑也不同
最麻烦的不是注释写错了，而是它看起来完全没影响——直到某天某个浏览器、某次构建、某个模板渲染顺序变了，它才突然冒出来搞破坏。留空行比留错注释安全得多。
