HTML中文乱码主因是文件实际编码与声明不一致，需统一为UTF-8（无BOM），确保<meta charset="UTF-8">在<head>最前、服务器响应头正确、外部资源也用UTF-8。
HTML 文件保存编码不是 UTF-8 会导致中文乱码
浏览器按声明的编码（比如 <meta charset="UTF-8">）去读文件，但如果你用记事本或某些编辑器保存时选了 GBK 或 ANSI，那实际字节流和声明不匹配，中文就变成方块或问号。
- 用 VS Code、Sublime、WebStorm 等现代编辑器时，右下角看当前编码，点它 → 选
Save with Encoding→ 强制存为UTF-8 - 别信“另存为”对话框里默认的“UTF-8”，有些编辑器（如老版记事本）标的是
UTF-8，实际存的是UTF-8 with BOM，BOM 有时会干扰 PHP 输出或 Node.js 服务端响应 - Linux/macOS 下用
file -i filename.html查真实编码；Windows 可用 PowerShell：Get-Content -Encoding UTF8 -Raw filename.html | Out-Null配合错误提示判断
<meta charset> 声明位置或写法错误
<meta charset> 必须在 <head> 里，且越靠前越好——浏览器解析到这一行才开始按 UTF-8 解码后续内容。如果它被卡在 JS、CSS 或其他 meta 后面，前面的中文可能已按默认编码（通常是 ISO-8859-1）错解了。
- 确保它是
<head>中第一个非空格、非注释的标签，紧贴<head>开始后写 - 只用
<meta charset="UTF-8">，不要写成<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">—— 后者是旧写法，部分老旧环境支持不稳定 - 如果页面由模板引擎生成（如 EJS、Thymeleaf），检查是否被动态插入的 head 内容挤到了后面
服务器响应头 Content-Type 覆盖了 HTML 中的 meta 声明
当 Web 服务器（如 Nginx、Apache）或后端框架（如 Express、Flask）返回 HTTP 响应头 Content-Type: text/html; charset=iso-8859-1，浏览器会优先信任这个头，直接忽略 HTML 里的 <meta charset>。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- Nginx 配置中检查是否有
charset iso-8859-1;或缺失charset utf-8;；静态 HTML 推荐显式加charset utf-8; - Express 中若用
res.sendFile()，默认不带 charset，需手动设置：res.set('Content-Type', 'text/html; charset=utf-8') - PHP 中如果开头有空格或 BOM，
header()可能失效，导致没发 charset 头——用hexdump -C file.php | head检查 BOM
从外部引入的 JS/CSS 文件本身编码不对
HTML 页面正常，但内嵌的 <script src="app.js"></script> 或 <link rel="stylesheet" href="style.css"> 里中文注释或字符串乱码，说明这些资源文件自己没存成 UTF-8。
立即学习“前端免费学习笔记（深入）”；
- 单独打开 JS/CSS 文件，用编辑器确认并重存为
UTF-8（无 BOM） - CSS 中如果用了
@charset "UTF-8";，必须放在第一行、最开头，前面不能有任何字符（包括空格、BOM、注释） - Webpack/Vite 等构建工具默认处理 UTF-8，但如果源文件是 GBK，需在 loader 中配置
encoding: 'gbk'显式转码，否则打包后仍乱码
真正卡住人的往往不是某个单一设置，而是编码在「文件保存→HTTP头→HTML声明→外部资源」这条链上某一处悄悄掉了队。调的时候别只盯一个地方，挨个验真实字节、真实响应头、真实渲染结果。
