Patchwork/utf8可纯PHP实现UTF-8处理，无需mbstring扩展，但需显式调用Bootup::init()启用函数重载，且不自动修复乱码，须配合pcrov/unicode校验。
直接用 composer require patchwork/utf8 就能装上
它不依赖扩展，纯 PHP 实现，装完就能替代原生字符串函数。不像 mbstring 那样得先确认服务器是否启用——只要 PHP ≥ 5.4，pcntl 或 iconv 有任一可用（通常都有），就能跑起来。
安装命令执行后，Composer 会自动注册 autoloader，无需手动 require 或 include。但注意：它默认不自动替换原生函数，必须显式启用“函数重载”机制。
- 在项目入口（如
index.php或框架的 bootstrap 文件）顶部，加一行Patchwork\Utf8\Bootup::init(); - 这行代码会让
strlen()、substr()、strpos()等自动转为多字节安全版本 - 如果只在部分模块用，可改用
Patchwork\Utf8\Utf8::replaceNativeFunctions();控制范围
mb_* 函数没装或被禁用时，Patchwork 是唯一可靠 fallback
很多共享主机或 Docker 容器里，mbstring 要么没编译，要么被 disable_functions 拦掉。这时 mb_strlen($str) 直接报 Call to undefined function，而 Patchwork 的 Patchwork\Utf8\Utf8::strlen($str) 仍可用。
它内部优先尝试 mbstring，失败后自动切到纯 PHP 实现（基于 UTF-8 字节模式匹配），结果和 mb_strlen() 一致。但要注意：
立即学习“PHP免费学习笔记（深入）”；
- 性能比原生
mb_*低约 20–30%，高并发场景别在循环里高频调用 - 不支持所有
mb_*功能，比如mb_ereg_replace()这类正则函数它不覆盖 - 若你已用
mb_internal_encoding('UTF-8')，Patchwork 会尊重该设置；没设则默认按 UTF-8 处理
别指望它自动修复乱码，utf8_validate() 得自己加校验逻辑
Patchwork 解决的是“操作安全”，不是“编码纠错”。它不会把 "café\x80"（含非法字节）自动清理成有效 UTF-8——这种字符串传给 Patchwork\Utf8\Utf8::strlen() 仍可能返回错误长度，甚至抛出警告。
真正防崩的做法是：入库或渲染前，先用 pcrov/unicode 的 utf8_validate() 检查，再决定丢弃、替换或修复：
if (!\Pcrov\Unicode\utf8_validate($input)) {
$input = \Pcrov\Unicode\utf8_clean($input); // 替换非法字节为
}
只靠 Patchwork + Bootup::init()，解决不了源头脏数据。它让 substr($input, 0, 10) 不截断汉字，但前提是 $input 本身是合法 UTF-8。
和 mbstring 共存时，函数重载顺序容易踩坑
如果你既开了 mbstring.func_overload（PHP.ini 设置），又调了 Patchwork\Utf8\Bootup::init()，两个重载机制会冲突——strlen() 可能被覆盖两次，行为不可预测。
稳妥做法是二选一：
- 服务器可控 → 关掉
mbstring.func_overload（已废弃，PHP 8.0+ 移除），只用 Patchwork - 已有大量
mb_*调用 → 不启用 Patchwork 的函数重载，改用其静态方法，例如Patchwork\Utf8\Utf8::substr($str, 0, 5) - 混用时务必测试：
var_dump(function_exists('strlen'))和var_dump(\Patchwork\Utf8\Utf8::strlen('a①b'))是否一致
最常被忽略的点：Patchwork 的重载只影响当前进程，CLI 和 Web 请求是独立的——你在 CLI 脚本里 init 了，不影响 Apache 子进程，得每个入口都写。
