网页乱码需确保文件编码、响应头、meta标签三者统一为utf-8：先确认静态文件为utf-8无bom编码，再配置nginx的charset、charset_map、charset_types，并在html中保留。
直接在 Nginx 的 http 块里写 charset utf-8; 是不够的——它只影响 Nginx 自己生成的响应（比如 404 页面），对静态 HTML、CSS、JS 文件默认不生效。要真正解决网页源码乱码，关键不是“加个 charset”，而是让响应头、文件内容、浏览器解析三者统一为 UTF-8。
确保静态文件本身是 UTF-8 编码
这是前提，否则再怎么配响应头也没用：
- 用 VS Code 打开 HTML/CSS/JS 文件 → 右下角查看编码 → 点击后选 “Save with Encoding” → 选 UTF-8（无 BOM）
- Notepad++ 用户：菜单栏「编码」→「转为 UTF-8 编码」→ 避免勾选 “BOM”
- 验证是否含 BOM：终端执行
head -c 3 yourfile.html | xxd，若输出ef bb bf就说明有 BOM，需清除
正确配置 charset + charset_types 启用自动追加
仅 charset utf-8; 不会为 CSS/JS/JSON 等加 charset=utf-8，必须配合 charset_map 和 charset_types：
-
charset utf-8;放在http块最外层，设全局默认 -
charset_map "" utf-8;必须存在（空字符串映射到 utf-8），否则 charset 不生效于静态响应 -
charset_types明确列出要加 charset 的 MIME 类型，例如：charset_types text/css text/javascript text/plain application/json application/xml;
对 autoindex（目录列表）和 HTML 响应单独加固
开启 autoindex on; 时，Nginx 生成的 HTML 默认没有 <meta charset>，浏览器可能按 Latin-1 解析 UTF-8 字节：
- 在对应
location块中加：add_header Content-Type "text/html; charset=utf-8"; - 同时确保该 location 的
charset_types包含text/html - HTML 文件内仍要保留
<meta charset="UTF-8">（放在最前面，唯一且小写）
反向代理场景下不覆盖后端设置
如果用了 proxy_pass，Nginx 默认尊重后端返回的 Content-Type 头：
- 后端（如 PHP/Node.js）已输出
Content-Type: text/html; charset=utf-8，Nginx 不会重复添加 - 若后端未设 charset，才由 Nginx 的
charset+charset_types补上 - 需要强制统一时，可用
proxy_hide_header Content-Type;+add_header Content-Type ...;，但易出错，一般不推荐
不复杂但容易忽略——乱码问题往往卡在文件编码、响应头、meta 标签三者不一致上，逐项核对比盲目改配置更有效。
