mbstring扩展未启用是导致中文、日文、emoji等UTF-8字符处理出错的根本原因，需通过php -m、php -i、检查扩展文件及配置路径等步骤精准定位并启用。
不是“必须”，但处理中文、日文、emoji 或任何 UTF-8 多字节字符时，不开启 mbstring 扩展几乎必然出错——mb_strlen() 报错、json_encode() 返回空、substr() 截出乱码，这些都不是配置问题，而是函数根本没加载。
Call to undefined function mb_strlen() 怎么快速定位原因
这个错误只说明一件事：mbstring 扩展没加载成功。别急着改代码，先查环境：
- 运行
php -m | grep mbstring—— 有输出才表示已启用；若无，再查是否安装了扩展文件 - 运行
php -i | grep "mbstring support"—— 必须看到mbstring support => enabled，光有模块名不够 - Linux/macOS 查
php-config --extension-dir下有没有mbstring.so；Windows 查php.ini中extension_dir指向的目录下是否有php_mbstring.dll - 在 Nginx + PHP-FPM 场景下，
php.ini可能被www.conf覆盖：检查/etc/php/*/fpm/pool.d/www.conf是否有php_admin_value[disable_functions] = mb_strlen这类限制
trae、Docker、Homebrew 等非系统 PHP 怎么开 mbstring
这类环境用的是独立 PHP 实例，系统级配置完全无效，必须找对配置文件：
-
trae用户执行trae php --ini，拿到路径如/Users/xxx/.trae/php/8.2/php.ini，在[ExtensionList]段添加extension=mbstring（注意：不是mbstring.so，也不是php_mbstring.dll） - Docker 镜像若基于
php:alpine，需在 Dockerfile 中加RUN docker-php-ext-install mbstring；若用php:apache，则通常已预装，但需确认docker exec -it xxx php -m | grep mbstring - Homebrew 安装的 PHP（如
php@8.2），扩展包名为php82-mbstring（macOS）或通过brew install php-mbstring补装，然后检查$(brew --prefix)/etc/php/8.2/php.ini
mb_internal_encoding() 不设会怎样
它不控制输入输出，只决定所有未显式传编码参数的 mb_* 函数默认用什么编码解析字符串。PHP 7.4+ 默认是 UTF-8，但旧版本或 CLI 下可能 fallback 到 ISO-8859-1，导致：
立即学习“PHP免费学习笔记（深入）”；
-
mb_strlen("你好")在未设内部编码且 locale 是C时返回 6（字节数），而非 2（字符数） -
mb_substr($s, 0, 5)按错误编码截断，结果不可控 - CLI 脚本尤其危险——终端
LANG环境变量可能覆盖 PHP 内部判断
所以建议在脚本开头统一写：mb_internal_encoding('UTF-8');，别依赖默认值。
mb_regex_* 函数为什么比 preg_* 慢很多
真正拖慢性能的不是 mbstring 本身，而是 mb_ereg()、mb_eregi() 这类正则函数——它们底层调用 PCRE 的多字节模式，每次匹配都要做编码边界检测，开销远高于 preg_match()。更关键的是：
-
mb_ereg系列已在 PHP 7.3 起被标记为废弃，PHP 8.0+ 彻底移除 - 替代方案是
preg_match('//u', $str)—— 加上u修饰符即可让preg_*支持 UTF-8 多字节匹配 - 如果必须用
mbstring做编码转换（如mb_convert_encoding()），注意避免在循环里反复调用，提前转好再复用
最常被忽略的一点：你写的 mb_strlen($s) 能跑通，不代表 mbstring 就真启用了——有些 Docker 镜像或一键环境会伪造函数存在性，实际调用仍走字节逻辑。务必用含中文的字符串实测，比如 var_dump(mb_strlen("测试") === 2);。
