mbstring扩展需手动启用并配置：在对应php.ini中取消extension=mbstring注释，添加mbstring.language=neutral和mbstring.internal_encoding=utf-8，重启服务后生效；func_overload已废弃，cli与web环境php.ini常不同，须分别确认。
mbstring 扩展没启用，mb_strlen 直接报错
PHP 8.5 默认不启用 mbstring，哪怕你装了扩展，php.ini 里没开，调用任何 mb_* 函数都会提示 Call to undefined function mb_strlen()。这不是版本问题，是配置开关没拨对。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 运行
php -m | grep mbstring确认扩展已编译安装（linux/macos）或看phpinfo()输出里有没有mbstring模块 - 找到真实生效的
php.ini：执行php --ini，别改错文件（比如改了 CLI 的，但 Web 用的是 apache/nginx 下的另一份） - 在对应
php.ini里取消注释这行：extension=mbstring（windows 下可能是extension=php_mbstring.dll） - 重启 PHP 服务（
sudo systemctl restart php-fpm或重启 Apache/Nginx）
默认编码设成 UTF-8，否则 mb_* 行为不一致
mbstring 很多函数（如 mb_substr、mb_strtolower）依赖内部编码，默认是 ISO-8859-1，不是 UTF-8。你在 UTF-8 环境下不显式指定，就可能切错字、转错大小写、甚至返回空字符串。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
php.ini中加这两行（必须写在extension=mbstring启用之后）：mbstring.language = Neutralmbstring.internal_encoding = UTF-8 - 不要用
mb_internal_encoding('UTF-8')在脚本里动态设——它只影响当前请求，且若被多次调用还可能冲突；ini 配置更稳 - 验证是否生效：写个
<?php echo mb_internal_encoding(); ?>，输出应为UTF-8
Web 环境下 mbstring.func_overload 已废弃，别碰
PHP 7.2 起 mbstring.func_overload 就被标记为废弃，PHP 8.x 完全移除。如果你在旧文档里看到让它把 strlen 自动替换成 mb_strlen，现在一设就报 Unknown configuration directive 'mbstring.func_overload'。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 从
php.ini彻底删掉mbstring.func_overload这行，别注释留着 - 代码里该用
mb_strlen($str)就明写，别指望“自动覆盖”——PHP 不再支持这种魔术，强行模拟反而容易漏掉边界情况 - 如果项目大量用原生字符串函数，考虑封装一层兼容函数，而不是依赖已被砍掉的机制
CLI 和 Web 的 php.ini 常常不是同一份
你在终端跑 php -r "echo mb_internal_encoding();" 返回 UTF-8，但网页里 phpinfo() 显示 ISO-8859-1？大概率是 CLI 用一份 php.ini，而 Apache/Nginx + PHP-FPM 各用各的配置文件，改漏一个就半残。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 分别查清楚：
CLI：执行php --ini
Web：建个info.php写<?php phpinfo(); ?>，搜 “Loaded Configuration File” - 两个地方都要确认
extension=mbstring和mbstring.internal_encoding = UTF-8存在且未被注释 - PHP-FPM 场景下，还要检查 pool 配置（如
/etc/php/8.5/fpm/pool.d/www.conf）里有没有php_admin_value[mbstring.internal_encoding] = UTF-8这类覆盖项
最常卡住人的点，是以为“扩展装了=能用”，其实只是跨过了第一道门；真正让 mb_* 可靠工作的，是 ini 里那几行不起眼的配置，以及确认它们确实被当前运行环境加载了。