必须写成text/html; charset=utf-8，含完整MIME类型与标准小写带横杠编码；单独charset=utf-8、缺text/html、大小写错误或无横杠均无效，且响应头优先级高于<meta charset>。
Content-Type响应头里charset怎么写才有效
必须写成 text/html; charset=utf-8（注意分号、空格、小写），不能漏掉 text/html; 前半部分。写成 charset=utf-8 单独一行、或 Content-Type: utf-8、或 charset=UTF8 都无效。
常见错误现象：
-
Content-Type: text/html; charset=utf8—— 缺少横杠，IANA 注册值是utf-8，部分 WebView 会 fallback 到 ISO-8859-1 -
Content-Type: charset=utf-8—— 缺失 MIME 类型，浏览器直接忽略整个字段 -
Content-Type: text/html; charset=UTF-8—— 大写不报错但非标准，某些老旧代理可能截断
Apache里AddDefaultCharset和Header set Content-Type冲突吗
会冲突，且 AddDefaultCharset 优先级更高，它会覆盖你用 Header set 手动写的 Content-Type。
使用场景：如果你只服务 HTML，AddDefaultCharset UTF-8 最省事；但若同时提供 text/plain API 接口，它会把 JSON 响应也打上 charset=utf-8，导致部分客户端解析失败。
立即学习“前端免费学习笔记（深入）”；
推荐做法：
- 删掉
AddDefaultCharset - 改用
Header set Content-Type "text/html; charset=utf-8"，并加early标志确保它在其他模块前生效：Header set Content-Type "text/html; charset=utf-8" early - 对非 HTML 资源（如
.js、.css）单独配置 MIME 类型，避免误设 charset
Nginx的charset指令为什么有时不生效
charset utf-8; 只对 text/html、text/css、application/javascript 等白名单类型自动加 charset，对 text/plain 或自定义类型（如 application/vnd.api+json）完全不处理。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
容易踩的坑：
- 静态 HTML 文件被 Nginx 当作
text/plain发送（比如没配types或后缀未注册），此时charset指令静默失效 - 在
http块设了charset，但server块又用add_header覆盖了Content-Type，导致 charset 丢失 - 用了
charset utf-8;后又手动add_header Content-Type ...，后者会完全取代前者
验证方法：用 curl -I your-site.com/index.html 看响应头，确认 Content-Type 字段完整包含 charset=utf-8。
Node.js（Express）中res.set()调用时机很关键
res.set('Content-Type', 'text/html; charset=utf-8') 必须在 res.send()、res.json()、res.sendFile() 之前调用，否则无效——这些方法内部会自动设置响应头，后续 set() 被忽略。
性能影响：对每个 HTML 响应都手动设头，比全局中间件稍慢，但可读性高；若用中间件统一处理，需排除非 HTML 路由（如 /api/），否则 JSON 响应也会被硬塞 charset。
安全提示：不要在中间件里无差别写 res.set('Content-Type', 'text/html; charset=utf-8')，否则 res.download() 发送二进制文件时会导致损坏。
正确写法示例：
app.get('/page', (req, res) => {
res.set('Content-Type', 'text/html; charset=utf-8');
res.send('<!DOCTYPE html><html><head><meta charset="utf-8"></head><body>OK</body></html>');
});
真正容易被忽略的是：服务端响应头和前端 <meta charset> 不一致时，浏览器以响应头为准，<meta> 完全被跳过——这点在调试乱码时最常误判。
