最可靠方式是修改php.ini中default_charset为"default_charset = \"UTF-8\""，需用phpinfo()确认配置文件路径、取消注释或新增该行、重启Web服务器；ini_set无效因不控制响应头且受SAPI限制。
PHP配置文件中修改default_charset的正确位置
直接改php.ini是最可靠的方式，但要注意不是所有环境都读取同一份配置文件。用phpinfo()确认Loaded Configuration File路径，否则改了也没生效。
找到对应php.ini后，搜索default_charset，修改为：
default_charset = "UTF-8"
如果该行被注释（开头有分号），去掉分号；如果不存在，就在[PHP]段落下新增这一行。改完必须重启Web服务器（如Apache或PHP-FPM），单纯刷新页面不生效。
为什么ini_set('default_charset', 'UTF-8')经常失效
这个函数只能在运行时修改当前脚本的default_charset，但它**不控制HTTP响应头中的Content-Type**，也不影响header()未显式设置时的默认行为。更关键的是：它不能覆盖已由SAPI（如Apache模块）提前发送的响应头。
立即学习“PHP免费学习笔记（深入）”；
- 在CLI模式下有效，但在Web SAPI中常被忽略
- 若脚本开头已有
header('Content-Type: text/html; charset=ISO-8859-1')，后续ini_set完全无效 - 某些PHP版本（如7.4+）对运行时修改
default_charset做了限制，仅允许在php.ini中设定
Web服务器层也要同步处理字符集
即使PHP设了default_charset = "UTF-8"，Apache或Nginx仍可能按自身配置加响应头，造成冲突。例如Apache的AddDefaultCharset指令会覆盖PHP行为。
检查并禁用这类干扰：
- Apache：确认
httpd.conf或虚拟主机配置中没有AddDefaultCharset，或设为AddDefaultCharset off - Nginx：确保没有
charset utf-8;或charset off;在server或location块中与PHP响应头冲突 - PHP-FPM：若使用
fastcgi_param传递CONTENT_TYPE，不要硬编码非UTF-8值
验证是否真正生效的三个检查点
别只信phpinfo()里显示的default_charset值，要实测响应头和实际渲染：
- 用
curl -I http://yoursite/test.php看返回头是否含Content-Type: text/html; charset=UTF-8 - 在PHP脚本中输出
var_dump(headers_list());，确认没有重复或冲突的Content-Type头 - 浏览器开发者工具 → Network → Response Headers → 查看真实发送的
Content-Type，同时打开Console看是否有编码警告（如“Resource interpreted as Document but transferred with MIME type text/plain”）
最容易被忽略的是：当PHP输出缓冲开启且内容已部分输出时，header()调用失败，此时default_charset不会自动补救——必须确保无任何前置输出（包括BOM、空格、echo）。
