php乱码根本原因是mb_internal_encoding未设或设错：该函数定义mb_*函数默认编码，不自动影响$_post/$_get/echo；须在脚本开头显式设为'utf-8'，并与html、数据库、文件编码严格一致。
PHP中mb_internal_encoding设错会导致整个流程乱码
很多PHP脚本在接收中文表单或输出JSON时突然出现问号或，根本原因不是数据库或前端问题，而是mb_internal_encoding没设对，或者压根没设。这个函数定义了PHP内部字符串函数（如mb_strlen、mb_substr）默认使用的编码，但它**不自动影响$_POST、$_GET或echo的行为**。
实操建议：
- 在所有脚本最开头（甚至早于session_start）调用
mb_internal_encoding('UTF-8')，且必须与HTML声明、数据库连接、文件保存的编码保持一致 - 不要依赖php.ini里的
default_charset来“代替”它——mb_*系列函数只认mb_internal_encoding的设置 - 检查当前值用
mb_internal_encoding()（无参数），别只信配置文件
接收用户输入时$_POST和$_GET本身不转码
PHP不会自动把HTTP请求体里的GBK或UTF-8字节流转换成内部编码。如果前端页面是UTF-8但用户用老旧浏览器提交，或API客户端发来GBK编码的application/x-www-form-urlencoded数据，$_POST['name']拿到的就是原始字节流，直接拿去mb_strlen会出错。
实操建议：
- 强制要求客户端用UTF-8提交，并在HTML里写
<meta charset="UTF-8">，同时后端校验$_SERVER['CONTENT_TYPE']是否含charset=utf-8 - 若必须兼容非UTF-8输入，先用
mb_detect_encoding试探（注意它不可靠），再用mb_convert_encoding转成UTF-8，例如：mb_convert_encoding($_POST['name'], 'UTF-8', 'GBK, BIG5, ASCII') - 避免用
iconv替代mb_convert_encoding——前者遇到非法字节直接报错，后者可加//IGNORE或//TRANSLIT选项容错
htmlspecialchars不指定encoding参数等于埋雷
PHP 5.4+ 默认htmlspecialchars用UTF-8，但老版本默认ISO-8859-1。如果你的字符串是UTF-8，却没传encoding参数，在PHP 5.3或某些SAPI（如CGI模式）下会把中文转成空字符串或乱码，而且不报错。
实操建议：
- 永远显式传参：
htmlspecialchars($str, ENT_QUOTES, 'UTF-8')，哪怕你确定环境是UTF-8 - 配合
mb_check_encoding($str, 'UTF-8')前置校验，防止脏数据绕过转义直接输出 - 对JSON输出，别用
htmlspecialchars，改用json_encode($data, JSON_UNESCAPED_UNICODE)，否则中文会被转成\uXXXX
MySQL连接层编码不匹配会让mysqli_real_escape_string失效
即使PHP内部用UTF-8，如果MySQL连接没设对编码，mysqli_real_escape_string会对字节做错误转义，导致SQL注入漏洞或插入乱码。典型表现：存进数据库的是“æ些æ‡å”，查出来还是它，但mb_strlen算出来长度却是两倍。
实操建议：
- 创建连接后立刻执行
$mysqli->set_charset('utf8mb4')（不是utf8），或在DSN里加;charset=utf8mb4 - 确认数据库、表、字段都用
utf8mb4_unicode_ci，否则emoji和生僻字存不进去 - 别依赖
SET NAMES utf8——它只改连接层，不保证mysqli_real_escape_string行为同步
真正容易被忽略的点是：编码问题从来不是单点问题。一个mb_internal_encoding设错，可能让mb_substr截断中文、json_encode返回null、htmlspecialchars吞掉内容、PDO预处理绑定失败——而错误信息往往只显示“Invalid argument”，看不出跟编码有关。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
