Nginx统一声明静态资源字符编码比HTML的meta更可靠，需配置charset utf-8;与charset_types text/html text/css application/javascript等组合，且文件必须为UTF-8无BOM编码。
直接在 Nginx 配置中统一声明静态资源的字符编码，比依赖 HTML 或 CSS 文件内的 <meta charset> 或 @charset 更可靠。浏览器优先依据 HTTP 响应头中的 Content-Type 解析编码，若响应头缺失 charset=utf-8，即使页面写了 meta 标签，也可能被覆盖或忽略，导致中文乱码、样式失效、脚本解析错误。
必须配置 charset + charset_types 组合
仅写 charset utf-8; 不会生效，它必须与 charset_types 配合使用：
- 在
http或server块中添加：charset utf-8; - 紧接着配置：
charset_types text/html text/css application/javascript text/plain application/json text/xml application/xml; -
text/html 必须包含——这是最常遗漏的一点，缺了它，.html 文件响应头就不会带
charset=utf-8 - 如果服务 JSON 接口（如前端直读静态 JSON），
application/json也需列入，否则部分浏览器可能按 ISO-8859-1 解析
确保文件本身是 UTF-8 无 BOM 编码
Nginx 不做内容转码，只负责声明编码方式。若文件实际不是 UTF-8，声明了也没用：
- 用命令检查：
file -i index.html或hexdump -C style.css | head -n1，确认无ef bb bf（BOM） - 编辑器保存时选“UTF-8 without BOM”，VS Code 默认即为此格式；Sublime Text、Notepad++ 需手动设置
- 构建工具（如 Vite、Webpack）输出通常无 BOM，但手动修改后易引入，建议 CI 中加入编码校验步骤
避免响应头与页面内声明冲突
HTML 中重复写 <meta charset="gbk"> 或 CSS 中写 @charset "GBK";，会与响应头产生竞争：
- 浏览器可能按 meta 解析，而实际字节是 UTF-8，结果出现“口口口”或方块
- 建议统一移除所有
<meta charset>（除非需兼容极老 IE），完全交由响应头控制 - CSS 文件中禁用
@charset规则——Nginx 已通过Content-Type: text/css; charset=utf-8显式声明
特殊场景处理：目录列表与中文文件名
启用 autoindex on; 时，目录页是 Nginx 动态生成的 HTML，需额外保障：
- 在对应
location块中加：add_header Content-Type "text/html; charset=utf-8"; - 确保服务器文件系统中中文目录/文件名本身是 UTF-8 字节（可用
ls -b验证） - 避免 Windows 下创建中文路径再挂载到 Linux，否则文件名可能是 GBK 字节，Nginx 匹配不到
