PHP 8.2 中 mb_str_split 可用且行为更稳定，始终返回数组而非 false；必须启用 mbstring 扩展，并显式指定 'UTF-8' 编码，避免依赖 mb_internal_encoding()。
mb_str_split 是 PHP 8.0+ 原生函数，PHP 8.2 完全支持，直接调用即可——但必须确认 mbstring 扩展已启用，且编码参数不能依赖默认值。
PHP 8.2 中 mb_str_split 是否可用？
可用，且行为更稳定：mb_str_split 自 PHP 8.0 起正式成为核心函数（不再需要手动兼容补丁），PHP 8.2 继承该实现。它不会返回 false（旧版可能失败返回 false），而是始终返回数组。
- 若未启用
mbstring扩展，调用会抛出Fatal error: Uncaught Error: Call to undefined function mb_str_split() - PHP 8.2 默认内部编码是
UTF-8，但mb_str_split的$encoding参数若为null，仍会 fallback 到mb_internal_encoding()当前值——这个值可能被运行时修改过，不可信 - 推荐显式传入
'UTF-8'，避免因框架或配置变更导致意外截断
正确调用格式与常见错误
标准调用只需三要素：字符串、长度、编码。漏掉任一环节都可能出错。
- ✅ 正确：
mb_str_split('你好世界', 1, 'UTF-8')→['你', '好', '世', '界'] - ❌ 错误：
mb_str_split('你好世界', 1)—— 编码未指定，若mb_internal_encoding()是ISO-8859-1，结果仍是乱码 - ❌ 错误：
mb_str_split('你好世界', 0)——$length必须 ≥ 1，否则返回空数组（PHP 8.2 不报错但逻辑失效） - ❌ 错误：
mb_str_split('你好世界', 2, 'gbk')—— 若字符串实际是 UTF-8 编码，用gbk解析会导致mb_substr内部计算偏移错乱，结果不可预测
替代方案：当 mbstring 不可用或需兼容旧环境
如果部署环境禁用了 mbstring（如某些精简 Docker 镜像），mb_str_split 无法使用，此时应退回到正则方案，而非降级用 str_split。
立即学习“PHP免费学习笔记（深入）”；
- ✅ 推荐替代：
preg_split('//u', $str, -1, PREG_SPLIT_NO_EMPTY)——//u启用 UTF-8 模式，能正确识别 Unicode 字符边界 - ⚠️ 注意：
mb_split('', $str)不可行，因为mb_split要求第一个参数是正则 pattern，空 pattern 会报警告并返回原字符串 - ⚠️
preg_split在超长字符串（如 >1MB）中性能略低于mb_str_split，但对常规文本无感
为什么不能用 str_split 处理中文？
str_split 按字节切分，UTF-8 中一个汉字占 3 字节，str_split('你好', 1) 实际拆成 6 个字节单元，再用 echo 或 json_encode 输出时就会显示乱码（如 "ä½ " 这类无效 UTF-8 片段）。
- 它不是“不支持中文”，而是根本没做多字节感知——连
mb_strlen都不用，纯 raw byte 操作 - 即使你在
str_split后用mb_convert_encoding补救，也已于事无补：字节已被错误截断，原始字符信息已丢失 - 唯一安全做法：从源头就用
mb_str_split或preg_split('//u')
真正容易被忽略的是编码一致性——字符串来源（GET 参数、数据库字段、文件读取）是否真为 UTF-8，比函数选型更重要。哪怕写对了 mb_str_split($s, 1, 'UTF-8')，若 $s 本身是 GBK 编码的二进制流，结果仍是错的。
