php中文乱码主因是http响应头未声明charset或编码不统一，须header("content-type: text/html; charset=utf-8")置于所有输出前，文件存为utf-8 without bom，数据库用utf8mb4。
PHP 输出中文乱码，90% 是因为 HTTP 响应头没声明 charset，或 PHP 内部编码与文件/数据库不一致。最直接有效的解法是 header() + 文件保存编码 + 数据库连接三者统一为 UTF-8（推荐 utf8mb4）。
header("Content-Type: text/html; charset=UTF-8") 必须放在输出之前
这个函数不是“建议加”，而是“必须加且位置严格”。只要在 echo、print、HTML 内容、甚至空格/BOM 之前没调用，浏览器就收不到正确的字符集声明，大概率 fallback 到 GBK 或 ISO-8859-1，中文立刻变 。
常见错误现象：
- 页面开头有 BOM（比如 UTF-8 with BOM 的编辑器保存），
header()报 Warning：“Cannot modify header information” - 脚本里先
echo ""或写了空行，header()直接失效 - 写了
header("Content-Type: text/html;charset=utf8")—— 缺少连字符，IE 和部分旧 UA 不识别utf8，必须写UTF-8
实操建议：
- 用 VS Code / Sublime 等编辑器确认文件编码为
UTF-8 without BOM - 在
<?php后第一行立即写：header("Content-Type: text/html; charset=UTF-8"); - 如果用了输出缓冲，可提前加
ob_start();，但别依赖它来“补救” header 失效
mb_internal_encoding('UTF-8') 影响 mb_* 函数行为，不自动修复页面乱码
这个函数只设定 PHP 内部多字节字符串处理的默认编码，比如 mb_strlen()、mb_substr()、mb_convert_encoding() 的隐式参数。它不会修改 HTTP 响应头，也不会影响 echo 或数据库读写。
容易踩的坑：
- 设了
mb_internal_encoding('UTF-8')就以为万事大吉，结果页面还是乱码 —— 因为 header 没设 - 和
ini_set('default_charset', 'UTF-8')混用：后者会影响htmlentities()默认编码，但同样不发 header - 在 CLI 模式下调用它，对 Web 输出完全无效
实操建议：
- 如需统一内部处理逻辑，可在入口文件开头加：
mb_internal_encoding('UTF-8'); - 避免在循环里反复调用，它只是设置一个全局状态
- 若项目混用多种编码（极少见），应在每次
mb_*()调用时显式传入$encoding参数，比如mb_substr($str, 0, 10, 'GBK')
PDO 连接 MySQL 必须用 utf8mb4，SET NAMES utf8 已过时
MySQL 的 utf8 实际是 utf8mb3，最多存 3 字节，不支持 emoji 和部分生僻汉字；真正兼容 Unicode 全集的是 utf8mb4。用错会导致插入失败、截断或 ? 替换。
关键点：
-
PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci"是最稳妥的初始化方式，比手动$pdo->exec("SET NAMES ...")更可靠 - 仅设
SET NAMES utf8mb4不够 —— 还得确保数据库、表、字段本身也是CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - mysqli 用户请用
mysqli_set_charset($link, 'utf8mb4')，不要用mysqli_query($link, "SET NAMES ...")，后者在某些配置下可能被忽略
实操建议：
- 建库时显式指定：
CREATE DATABASE db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 检查当前连接编码：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results; - 如果已有数据，转换需分步：改库/表/列的字符集，再用
CONVERT TO CHARACTER SET重导数据
php.ini 的 default_charset 是兜底项，但不能替代 header()
设 default_charset = "UTF-8" 后，PHP 会在没显式调用 header("Content-Type") 时自动补上 charset。听起来很省事，但有硬伤：
- 它只对
text/html类型生效，JSON、XML、CSV 等响应类型不会加 charset - 一旦脚本里写了
header("Content-Type: application/json")，这个配置就完全失效 - 共享主机通常不允许改 php.ini，你没法依赖它
实操建议：
- 有服务器权限时，可以设
default_charset = "UTF-8"作为保险，但仍要每页手动写 header() - 配合
output_handler = mb_output_handler可做透明转码，但会增加开销，且对已压缩/加密的内容不适用 - 更推荐的做法：把
header("Content-Type: ...")封装进基础控制器或模板引擎的 render() 方法里，避免遗漏
真正容易被忽略的是：**文件本身的编码、HTTP 响应头、数据库连接、HTML meta 标签这四者必须全部指向 UTF-8（utf8mb4），缺一不可。任何一个环节掉链子，乱码就会出现——而且往往只在特定字、特定浏览器、特定请求路径下复现，调试成本远高于预防成本。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
