使用 mb_substr 截取多字节字符串时必须显式指定编码参数（如 'utf-8'），否则易因编码不匹配导致乱码或截断；不可省略、传 null 或空字符串，且需避免依赖 mb_internal_encoding() 全局设置。
使用 mb_substr 截取多字节字符串时，**必须显式指定编码参数**，否则可能因默认编码不匹配导致乱码或截断错误。PHP 不会自动识别字符串编码，尤其在处理中文、日文、emoji 等 UTF-8 字符时，漏设编码是常见出错原因。
明确传入目标编码（推荐 UTF-8）
绝大多数现代项目使用 UTF-8 编码，调用时应直接写明：
$str = "你好，世界！?"; $result = mb_substr($str, 0, 5, 'UTF-8'); // ✅ 正确：显式指定 UTF-8 // 返回："你好，世界"
- 不要依赖
mb_internal_encoding()的全局设置，它可能被其他代码修改，也不保证与实际字符串编码一致 - 即使脚本已用
mb_internal_encoding('UTF-8')设置，默认编码，mb_substr仍优先以第四个参数为准 - 若字符串实际是 GBK 编码（如旧系统数据），则必须传
'GBK'，否则会解析错位
避免使用空字符串或 null 作为编码参数
以下写法是危险的：
// ❌ 错误：第三个参数为 null 或空字符串 mb_substr($str, 0, 5, null); mb_substr($str, 0, 5, ''); // ❌ 错误：省略编码参数（PHP 会尝试用内部编码，但不可靠） mb_substr($str, 0, 5); // 不推荐，行为不确定
- 省略编码时，函数退回到
mb_internal_encoding()的当前值，但该值可能不是字符串真实编码 - 传
null或空字符串会导致 PHP 使用平台默认编码（如 ISO-8859-1），对中文几乎必然出错
动态判断编码前先确认来源可信
如果字符串来源不确定（如用户输入、第三方 API），不要盲目用 mb_detect_encoding 自动识别：
-
mb_detect_encoding准确率有限，尤其对短文本或纯 ASCII 内容容易误判 - 更可靠的做法是：约定接口统一用 UTF-8，或在接收时强制转码（如
mb_convert_encoding($input, 'UTF-8', 'auto')） - 若必须检测，建议限定候选集：
mb_detect_encoding($str, ['UTF-8', 'GBK', 'BIG5'], true)，并配合业务逻辑校验
注意 emoji 和增补平面字符（4 字节 UTF-8）
UTF-8 中 emoji（如 ?）和部分汉字（如?）占 4 字节，但仍是单个 Unicode 码点。只要编码指定为 'UTF-8'，mb_substr 就能按字符而非字节切分：
$str = "Hello?世界"; echo mb_strlen($str, 'UTF-8'); // 输出：9（不是 13） echo mb_substr($str, 0, 6, 'UTF-8'); // 输出："Hello?"
- 这依赖于底层 mbstring 扩展正确支持 UTF-8 多字节解析（PHP 7.2+ 默认启用）
- 确保 php.ini 中未禁用
mbstring.func_overload（已废弃，不建议开启） - 避免混用
substr（字节级）和mb_substr（字符级）处理同一字符串
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
