php判断字符串长度性能差异_php strlen与mb_strlen对比【要点】_技术教程

strlen和mb_strlen在ASCII下性能差异可忽略，但处理UTF-8中文时必须用mb_strlen并显式指定编码，否则strlen返回字节数而非字符数，易致乱码或校验错误。

strlen 和 mb_strlen 在 ASCII 字符下性能几乎无差别

当字符串只含 ASCII 字符（如纯英文、数字、常见符号），strlen 和 mb_strlen 返回结果一致，但底层行为不同：strlen 直接返回字节数，mb_strlen 会调用多字节编码检测逻辑（即使当前是 ASCII）。实测百万次调用，差异在毫秒级，对绝大多数 Web 场景可忽略。

但要注意：mb_strlen 默认使用 mb_internal_encoding() 指定的编码，若未显式设置且环境编码不一致，可能引发隐性偏差。

没设 mb_internal_encoding('UTF-8') 时，某些系统会 fallback 到 ISO-8859-1，导致中文被误判为多个字符
Apache + mod_php 环境中，mb_internal_encoding 可能被 .htaccess 或 php.ini 覆盖
CLI 模式下该值常为空，mb_strlen 行为更不可控

处理中文或 UTF-8 字符串必须用 mb_strlen

strlen 对 UTF-8 中文返回的是字节数（如一个汉字占 3 字节），而你需要的是“字符数”——这时候 strlen 完全失效。例如 strlen('你好') 返回 6，mb_strlen('你好', 'UTF-8') 才返回 2。

常见错误场景：

用户昵称截断显示：用 substr($str, 0, 10) 配合 strlen 判断长度，结果切到 UTF-8 中间字节，输出乱码
表单长度校验：前端限制 20 字符，后端用 strlen 校验，用户输入 7 个汉字就超限（21 字节）
JSON 接口返回字段被截断：因长度判断错位，导致 json_encode 失败或内容损坏

mb_strlen 的 encoding 参数不能省略

虽然 mb_strlen($str) 看似简洁，但依赖全局 mb_internal_encoding，极易出问题。生产环境应始终显式传入编码：

// ✅ 推荐：明确指定
mb_strlen($str, 'UTF-8')

// ❌ 风险高：受运行时环境影响
mb_strlen($str)

尤其注意以下情况：

PHP 版本 ≥ 8.0 后，mb_internal_encoding 默认值从 ISO-8859-1 改为 UTF-8，但老项目升级后若未测试，可能暴露历史 bug
同一进程内多个模块可能调用 mb_internal_encoding() 修改全局状态，造成交叉污染
Composer 加载的第三方库如果擅自改 encoding，你的 mb_strlen 就不再可靠