根本原因是编辑器保存时默认忽略BOM或误用ANSI/GBK编码，导致文件实际编码与<meta charset="UTF-8">声明不一致；需明确选“UTF-8 with BOM”保存HTML文件，并确保服务器Content-Type头正确配置。
保存HTML文件时编码选UTF-8但实际没生效？
根本原因不是“没点UTF-8”，而是编辑器保存时默认可能忽略BOM或误用ANSI/GBK。Windows记事本里选“UTF-8”看起来对了，但底层常存为UTF-8 without BOM，而某些旧浏览器（尤其IE系）或本地双击file://打开时，会跳过<meta charset="UTF-8">直接按系统默认编码（如GBK）解析，立刻乱码。
实操建议：
- VS Code右下角状态栏显示“UTF-8”时，点击它 → 选
Save with Encoding→ 明确选UTF-8 with BOM（不是默认的UTF-8） - Notepad++：菜单栏
编码→转为UTF-8-BOM格式→ 再保存 - 记事本无法生成BOM，不推荐用于含中文的HTML保存；若必须用，保存后需用其他工具补BOM或改用
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
为什么<meta charset="UTF-8">有时不起作用？
这个标签只在HTTP响应头缺失或不一致时兜底。当你双击本地打开HTML文件（file://协议），没有HTTP头，全靠它；但一旦走Web服务器（Nginx/Apache/Express），服务器返回的Content-Type: text/html; charset=utf-8优先级更高——如果服务器配置错成charset=gbk或压根没设charset，<meta>会被无视。
检查与修复：
立即学习“前端免费学习笔记（深入）”；
- 浏览器按F12 → Network → 刷新页面 → 点index.html → 查Response Headers里的
Content-Type值 - Nginx配置需在
location块加：charset utf-8;（不是add_header） - Express中用
res.set('Content-Type', 'text/html; charset=utf-8')，且必须在res.send()前调用 -
<meta charset="UTF-8">必须放在<head>内、任何CSS/JS引用之前，且不能写成<meta charset='utf-8'/>（单引号+自闭合在部分解析器中失效）
保存为.html却变成.html.txt？
这是Windows隐藏已知文件扩展名导致的典型问题。你输入index.html，系统实际保存为index.html.txt，类型是文本文件而非网页文件，双击必然打不开或报错。
解决步骤：
- 文件资源管理器 → 查看 → 勾选
文件扩展名（取消“隐藏已知文件类型的扩展名”） - 记事本另存为时，“保存类型”务必选
所有文件，不能留默认的文本文档 (*.txt) - VS Code等编辑器保存时，文件名框里直接输
index.html，别加引号，也别手动敲.txt - 保存后右键属性 → 确认“类型”是“HTML Document”，不是“文本文档”
BOM到底要不要？
要，但仅限HTML文件。UTF-8 BOM（EF BB BF）在HTML中是安全的，现代浏览器都支持；它能强制本地打开时正确识别编码。但对CSS/JS文件，BOM会导致解析错误（如CSS @import失效、JS首行报SyntaxError），所以CSS和JS文件应存为UTF-8 without BOM。
关键提醒：
- 别用同一套流程处理所有文件：HTML用UTF-8 with BOM，CSS/JS用UTF-8 without BOM
- VS Code里不同文件类型可设不同编码：打开CSS文件 → 右下角编码 →
Save with Encoding→ 选UTF-8（无BOM） - 用
xxd或十六进制编辑器查BOM：文件开头是ef bb bf即含BOM；纯3c 21 64 6f（对应<!do）则无
最易被忽略的一点：保存操作本身不等于编码变更。改完<meta>标签后，必须重新用正确编码保存文件，否则HTML源码和文件存储编码依然不匹配——乱码就卡在这一步。
