mb_strlen()才是正解，它按字符计数，能正确识别UTF-8下的中文；strlen()按字节算，中文占2–4字节导致结果不准，如"你好"返回6而非2。
PHP里strlen()和mb_strlen()到底谁算中文字数
strlen()按字节算，一个中文占2–4字节（取决于编码），结果完全不准；mb_strlen()才是正解，它按字符计数，能正确识别UTF-8下的中文。用错函数是90%人踩坑的根源。
常见错误现象：strlen("你好")返回6（UTF-8下每个中文3字节），但你想要的是2。
- 必须指定编码：比如
mb_strlen($str, 'UTF-8')，不传第二个参数在某些环境下会 fallback 到mb_internal_encoding()，而这个值可能不是UTF-8 - 如果字符串来源不可控（如表单提交、文件读取），先用
mb_detect_encoding()粗略判断，但别依赖它——优先统一转成UTF-8再统计 - 性能上
mb_strlen()比strlen()慢，但对普通业务字符串（
GBK编码下怎么安全统计中文字符数
国内老系统、Windows记事本默认保存、部分数据库字段仍用GBK，这时候mb_strlen($str, 'GBK')才能准确返回“看起来像2个字”的结果。
使用场景：读取本地GBK编码CSV、对接遗留ASP系统接口、处理iconv('UTF-8', 'GBK', $str)后的字符串。
立即学习“PHP免费学习笔记（深入）”；
- 别混用编码：
mb_strlen(iconv('UTF-8', 'GBK', $str), 'UTF-8')这种写法会崩，第二参数必须匹配实际字节编码 - 检测是否GBK：可试
mb_check_encoding($str, 'GBK')，但注意它只校验合法性，不保证原始编码就是GBK - 如果不确定编码又不敢乱转，宁可先
mb_convert_encoding($str, 'UTF-8', 'UTF-8, GBK, BIG5')再统计，避免mb_strlen()返回FALSE
截取中文字符串时长度计算和实际显示不一致怎么办
统计完长度只是第一步，真正麻烦的是截断——mb_substr()必须和mb_strlen()用同一套编码，否则前端显示缺字、乱码或。
典型错误：mb_strlen($str, 'UTF-8')得出来是10，但用substr($str, 0, 10)硬切，结果最后一个中文被砍掉一半，变成乱码。
- 截取必须用
mb_substr($str, 0, 10, 'UTF-8')，第三个参数不能省 - 如果要兼容多编码，建议统一在入口处转UTF-8：
$str = mb_convert_encoding($str, 'UTF-8', 'auto')，之后所有mb_*函数都固定用'UTF-8' - 注意
mb_substr()的起始位置是字符偏移，不是字节偏移，所以mb_substr($str, 0, 5)一定取前5个完整字符，不会截断中文
为什么mb_strlen()有时返回FALSE？
这不是bug，是明确的错误信号：传入的字符串包含非法多字节序列，比如UTF-8里出现孤立的0xC0字节，或者混进了BOM以外的控制字符。
容易被忽略的地方：MySQL查询结果如果字段是TEXT且没设utf8mb4，可能存入不合法的4字节UTF-8（如emoji），PHP读出来就触发mb_strlen()失败。
- 先用
mb_check_encoding($str, 'UTF-8')验证，返回FALSE就说明有问题 - 修复方案：用
mb_convert_encoding($str, 'UTF-8', 'UTF-8')可自动剔除非法字节（注意：会丢失数据） - 更稳妥的做法是源头控制：数据库连字符集设为
utf8mb4，PDO连接加charset=utf8mb4，避免问题产生
