strlen() 计算字节数，mb_strlen() 计算字符数；含中文、emoji等时结果不同，校验、截断等应优先用 mb_strlen(“utf-8”)，仅ASCII场景可用 strlen()。
strlen() 和 mb_strlen() 的区别到底在哪
php里算字符串长度，strlen() 和 mb_strlen() 经常混用，但结果可能差好几倍——尤其含中文、emoji 或特殊符号时。strlen() 数的是字节数，mb_strlen() 数的是字符数，底层逻辑完全不同。
比如 "你好"： strlen("你好") 返回 6（UTF-8 下每个汉字占 3 字节）， mb_strlen("你好", "UTF-8") 返回 2（两个字符）。
- 只要字符串含非 ASCII 字符（中文、日文、emoji、带重音的拉丁字母），必须用
mb_strlen() -
mb_strlen()第二个参数不写可能出错：默认编码取决于mb_internal_encoding()，而这个值未必是 UTF-8，建议显式传"UTF-8" -
mb_strlen()在未启用 mbstring 扩展时会报致命错误Fatal Error: Uncaught Error: Call to undefined function mb_strlen()，上线前务必检查扩展是否开启
为什么 var_dump(strlen($str)) 看着对，但业务逻辑却错了
常见陷阱：用 strlen() 做表单校验（比如限制“用户名最多 10 个字符”），用户输 “张三” 就卡住——因为后端以为占了 6 字节，误判超长。这不是函数错了，是语义错配。
- 用户感知的“长度” = 字符个数，不是字节数，校验、截断、显示计数都该用
mb_strlen() - 数据库字段长度限制（如
VARCHAR(20)）按字符算，和mb_strlen()对齐；但某些底层操作（如 socket 发送、加密输入）可能真需要字节数，这时才用strlen() - 别依赖 ide 提示或本地测试环境的默认编码——docker 容器、线上 PHP 版本、甚至
php.ini里的default_charset都可能影响mb_internal_encoding()结果
mb_strlen() 不生效？先查这三件事
写了 mb_strlen($str, "UTF-8") 还是返回异常值，大概率不是函数问题，而是输入本身已损坏或编码混乱。
- 确认字符串来源：从 POST、文件读取、数据库查出的字符串，是否在中途被错误转码过？比如用
iconv("GBK", "UTF-8", $str)失败后返回false，再传给mb_strlen()就变成算false的长度（即 1） - 检查是否被 trim() 或正则污染：
trim()默认只处理 ASCII 空白符，对全角空格、零宽空格（u200b）无效，这些字符会被mb_strlen()算进去 - 用
mb_detect_encoding($str, ["UTF-8", "GB2312", "ISO-8859-1"], true)辅助判断真实编码，但注意它不可靠——返回false很常见，别当真理用
性能有差别吗？什么场景可以放心用 strlen()
纯英文、数字、ASCII 符号组成的字符串（比如 Token、base64 编码串、URL path），strlen() 比 mb_strlen() 快 3–5 倍，因为后者要逐字节解析多字节序列。
立即学习“PHP免费学习笔记（深入）”；
- API 接口里校验
Authorizationheader 的 Bearer token 长度，用strlen()完全 OK - 生成固定长度随机字符串（如
bin2hex(random_bytes(16))），结果全是十六进制字符，也适用strlen() - 但只要字符串来自用户输入、外部 API、数据库或文件，一律默认走
mb_strlen()——省下的那点 CPU 时间，远不如一次中文截断错位带来的排查成本
最麻烦的不是选错函数，而是同一项目里一部分用 strlen()、一部分用 mb_strlen()，还共享同一个长度校验逻辑。编码意识得贯穿输入入口，而不是等出错再补。