加 AddDefaultCharset UTF-8 能解决中文乱码，因它强制 Apache 对所有响应添加 Content-Type: text/html; charset=UTF-8 头，使浏览器不再猜测编码而直接按 UTF-8 解码。

Apache 默认不发送 Content-Type 的 charset 参数，浏览器靠自动探测或历史缓存猜编码，一猜就容易错——中文乱码基本都卡在这一步。直接在 Apache 配置里强制声明 UTF-8 字符集，是最稳、最省事的解法。

为什么加 AddDefaultCharset UTF-8 就能解决问题

它会让 Apache 对所有响应（除非被脚本显式覆盖）自动加上 Content-Type: text/html; charset=UTF-8 头。浏览器看到这个头，就不会瞎猜，直接按 UTF-8 解码 HTML 和内联文本。

注意：这个指令只影响 Apache 自己生成的响应头，不影响 PHP 等后端脚本自己用 header() 发送的头；如果后端已发了 charset，Apache 不会覆盖它。

常见错误现象：Content-Type: text/html 没带 charset，或者写成了 gb2312/gbk，但页面实际是 UTF-8 编码保存的。

• 优先加在虚拟主机配置段（<virtualhost></virtualhost> 内），作用范围明确
• 不建议加在全局 httpd.conf 顶层，可能意外影响静态资源（如 CSS/JS 文件）的响应头
• 如果用了 .htaccess，可用 AddDefaultCharset UTF-8，但需确保 AllowOverride 允许 FileInfo

PHP 页面中 header() 和 AddDefaultCharset 的冲突处理

PHP 脚本里如果写了 header('Content-Type: text/html; charset=GBK');，就会覆盖 Apache 的 AddDefaultCharset。这时候乱码不是 Apache 的锅，而是 PHP 自己发错了头。

使用场景：老项目迁移到 UTF-8 时，常遗漏修改 PHP 中硬编码的 charset 值。

• 检查 PHP 输出前是否调用了 header()，尤其注意框架的初始化逻辑（如 ThinkPHP 的 App::run() 前）
• 用浏览器开发者工具的 Network → Response Headers 真实查看最终发出的 Content-Type
• 临时调试可在 PHP 开头加 header_remove('Content-Type');，再重设，确认是否为 PHP 干扰

HTML meta charset 和 HTTP 头不一致时以谁为准

HTTP 响应头里的 charset 优先级高于 HTML 中的 <meta charset="GBK">銆備篃灏辨槸璇达紝鍗充娇缃戦〉鍐欎簡 meta锛屽彧瑕佹湇鍔″櫒澶村彂鐨勬槸 UTF-8锛屾祻瑙堝櫒灏辩敤 UTF-8銆