php post中文乱码的根本原因是请求体编码、php解析方式、脚本自身编码、数据库连接编码四者不一致；需依次确认html表单charset声明、accept-charset属性、content-type头、php.ini中default_charset、mysql连接及表结构编码是否统一为utf-8/utf8mb4。
PHP 接收 POST 中文乱码，根本原因不是“没加编码”，而是请求体编码、PHP 解析方式、脚本自身编码、数据库连接编码四者不一致。单纯在 PHP 文件开头写 header('Content-Type: text/html; charset=utf-8'); 或改 mb_internal_encoding() 无法解决 POST 乱码。
确认浏览器发送的 POST 编码是否为 UTF-8
POST 数据乱码的第一环永远在客户端。如果 HTML 表单没声明编码，浏览器可能按系统默认（如 GBK）编码提交：
- 表单页面的
<meta charset="utf-8">必须存在且在内靠前位置 - 表单标签要显式指定
accept-charset="UTF-8"，例如：<form method="post" accept-charset="UTF-8"></form> - 用 Chrome 开发者工具 → Network → 点开 POST 请求 → 查看 Request Headers 中的
Content-Type，应含charset=utf-8（如application/x-www-form-urlencoded; charset=UTF-8） - 若后端用 JavaScript 的
fetch或XMLHttpRequest提交，需手动设置请求头或确保FormData构造正确，避免 Blob / 字符串二次编码
PHP 不会自动根据 header 推断 POST 编码
$_POST 数组的值在 PHP 接收到请求体后就已完成解码（按 default_charset 或 input_encoding），之后再调 mb_convert_encoding() 或 iconv() 属于亡羊补牢，且极易出错。
- 检查 php.ini 中
default_charset = "UTF-8"（PHP 5.6+ 默认已是 UTF-8；旧版本需手动设） - 不要依赖
mb_internal_encoding("UTF-8")—— 它只影响 mbstring 系列函数的默认行为，不改变$_POST解码逻辑 - 关键配置是
php.ini中的enable_post_data_reading = On（必须开启，否则$_POST为空）和variables_order = "EGPCS"（确保 P 即 POST 被解析） - 若用 Nginx + PHP-FPM，确认
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;无路径截断，否则可能加载到错误编码的 PHP 文件
绕过自动解析，原始读取并手动解码
当无法控制前端编码（如对接遗留系统、第三方 H5 页面），最稳妥的方式是跳过 $_POST，直接读原始输入流，再按预期编码转换：
