PHP多语言编码问题本质是五要素（HTTP头、数据库连接、脚本文件、HTML meta、IDE默认编码）必须全部对齐为UTF-8/utf8mb4，任一环节错位即导致乱码或报错。
PHP 多语言编码问题不是“学不学得会”的问题，而是“漏掉哪一环就全崩”的问题。绝大多数乱码、报错、emoji 存储失败，都源于 HTTP 头、数据库连接、脚本文件本身、HTML meta 四者中至少一个没对齐。
header('Content-Type: text/html; charset=UTF-8') 必须在输出前调用
这个 header() 调用一旦被任何空白、echo、BOM 字节提前触发，就会报 “Cannot modify header information” 错误，且后续浏览器很可能按 ISO-8859-1 解析页面——中文立刻变问号或乱码。
- 确保 PHP 文件保存为 UTF-8 无 BOM 格式（编辑器里要手动选，Notepad++/VS Code 都有明确选项）
- 所有
header()调用必须出现在任何echo、print、HTML 输出之前，包括空行和空格 - 如果用了
require或include，检查被包含文件顶部有没有不可见字符（比如 BOM 或空行） - 开发时可临时加
if (headers_sent($file, $line)) { die("Headers already sent in $file on line $line"); }定位源头
MySQL 连接必须用 utf8mb4，不是 utf8
MySQL 的 utf8 是个历史包袱：它只支持最多 3 字节的 UTF-8 字符，不兼容 emoji 和部分生僻汉字；真正完整支持的是 utf8mb4。用错会导致插入失败、截断、或存成 ?。
- 建表时显式指定：
CREATE TABLE users (name VARCHAR(255)) CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; - 连接时强制设置：
mysqli_set_charset($conn, 'utf8mb4')（面向过程）或$pdo->setAttribute(PDO::MYSQL_ATTR_INIT_COMMAND, "SET NAMES 'utf8mb4'") - PHP 配置里
default_charset = "UTF-8"只影响输出，不改变 MySQL 行为，别指望它救场 - 检查当前连接编码：
SELECT @@character_set_database, @@collation_database;和SHOW VARIABLES LIKE 'character_set%';
mb_convert_encoding() 的第三个参数不能瞎填
mb_convert_encoding() 常被用来“猜转”用户上传的 GBK/Big5 文件内容，但它的第三个参数（源编码）如果写死或乱填，结果就是把原本正确的字符串越转越乱。
立即学习“PHP免费学习笔记（深入）”；
- 优先用
mb_detect_encoding($str, ['UTF-8', 'GBK', 'BIG5'], true)尝试检测，注意第三个参数true表示 strict 模式，更可靠 - 检测结果可能为
false，此时别硬转，先记录原始字节长度和十六进制 dump：bin2hex(substr($str, 0, 10))辅助判断 - 避免用
iconv('GBK', 'UTF-8//IGNORE', $str)处理未知来源数据——//IGNORE会静默丢字，出问题难追溯 - 对已知来源（如某旧系统导出 CSV），应固化源编码，而非依赖检测
$_POST 和 $_GET 的值默认不是 UTF-8 安全的
浏览器提交的表单数据编码取决于页面本身的 <meta charset> 和 HTTP Content-Type，但 PHP 不会自动校验或转换 $_POST 值。如果前端是 GBK 页面，$_POST['name'] 就是 GBK 字节流，直接入库等于埋雷。
- 不要在接收后立刻
mb_convert_encoding($_POST['name'], 'UTF-8', 'UTF-8')—— 这是无效操作，等同于白转 - 正确做法：确认页面声明了 UTF-8 后，用
mb_check_encoding($_POST['name'], 'UTF-8')做校验，失败则拒绝或打日志 - 对富文本或文件名等高风险字段，入库前务必用
htmlspecialchars($str, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8')输出转义，且第三个参数必须显式传'UTF-8' - 记住：
filter_input(INPUT_POST, 'name', FILTER_SANITIZE_STRING)已废弃，且不处理编码，别再用
最常被跳过的其实是文件编码一致性：PHP 脚本自身、数据库连接、HTTP 响应头、HTML meta、甚至 IDE 默认编码，这五个点只要有一个是 GBK 或 ANSI，整个链路就可能断裂。调试时别只盯着数据库或浏览器，先用 bin2hex() 看原始字节，比猜快得多。
