HTML文件的charset声明必须与实际保存编码一致，否则注释中中文会乱码；应统一使用UTF-8 without BOM保存，<meta charset>须置于<head>最开头，且HTTP头与HTML声明需一致。
HTML 文件声明的 charset 必须与实际保存编码一致
浏览器解析 HTML 注释时不会单独处理编码，而是完全依赖文档整体的字符编码声明。如果 <meta charset="UTF-8"> 写了，但文件实际用 GBK 保存，注释里的中文就会显示为乱码——不是注释的问题，是编码错配。
实操建议：
- 用编辑器（如 VS Code、Sublime）确认并统一设置：保存编码为
UTF-8 without BOM -
<meta charset>必须放在<head>最开头，且不能被 JS 或条件注释阻断 - 避免在
<meta>前插入任何非 ASCII 字符（包括中文空格、全角符号） - 服务端返回的 HTTP
Content-Type头（如text/html; charset=utf-8）应与 HTML 内声明一致
HTML 注释语法本身不支持转义，但内容需符合编码上下文
HTML 注释格式是 <!-- ... -->，中间的内容**不经过 HTML 实体解码**，也不做 JS/CSS 那样的字符串转义。它只是原样跳过，所以只要编码正确，中文、emoji、甚至 base64 片段都能安全写入。
常见错误现象：
windows-shell-syntax
下载
在 Windows 上执行终端命令，或对比 Windows 与 Linux 的 Shell 语法时使用。建议先检测当前 Shell 是 PowerShell 还是 cmd.exe，再给出相应命令……
立即学习“前端免费学习笔记（深入）”；
- 注释里写了
<!-- 这里用了 -->→ - 但若文件存为 UTF-8，却误写成
<!-- 价格：¥100 -->而服务器返回charset=gbk→ ¥ 变成乱码 - 注释中混入不可见控制字符（如 U+200E 零宽左至右标记）可能破坏某些构建工具的解析
构建工具或模板引擎可能二次处理注释
像 Webpack、Vite、Vue SFC、Jinja2 这类工具，在编译阶段可能剥离、压缩或解析注释。它们通常不关心编码，但会按自身逻辑处理文本流——一旦输入流编码错误，输出就必然出错。
使用场景与对策：
- Webpack 的
html-webpack-plugin：确保template文件本身编码正确，不要依赖插件“自动修复” - Vue 单文件组件：注释写在
<template>内时，和普通 HTML 行为一致；写在<script>里则是 JS 注释，走 JS 编码规则 - 服务端模板（如 EJS、Nunjucks）：注释语法是
<!-- ... -->还是<%-- ... --%>？后者由模板引擎解析，可能提前解码或报错，需查对应文档
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>示例</title> </head> <body> <!-- 正确：中文注释，UTF-8 编码保存 --> <p>欢迎访问</p> <p><!-- 错误示例（仅用于演示）：若文件误存为 GBK，这行会乱码 --> <!-- 用户反馈：登录按钮点击无响应 --> </body> </html>
真正容易被忽略的是：本地开发时浏览器可能“猜对”编码（尤其 Windows 上），但部署到 Linux 服务器后，HTTP 头缺失或 Nginx 默认配置不带 charset utf-8，注释立刻暴露问题。
