explode('%', $str) 本身不会出错，问题在于输入字符串可能含URL编码（如%E6%96%87），导致误切；需先确认是否需保留编码完整性，再决定用explode或preg_split('/%(?![0-9A-Fa-f]{2})/')。
PHP 中用 explode() 按百分号 % 分割字符串会出错？
直接写 explode('%', $str) 通常能工作，但一旦字符串里有 URL 编码（如 %20、%E6%96%87）或你本意是“按字面意义的 % 切”，就容易切错——因为 % 本身不是正则元字符，explode() 不涉及转义，问题其实出在**你没意识到输入源已含编码逻辑**。
常见错误现象：
• 原字符串是 "a%b%c" → 正常切成三段
• 原字符串是 "name=%E6%96%87%E4%BB%B6" → 你本想保留完整 URL 编码，却切成 ["name=", "E6", "96", "87", "E4", "BB", "B6"]
- 先确认：你要分割的是「原始文本中的字面
%」，还是「想跳过 URL 编码里的%」？前者直接explode即可；后者得先解码或换正则 -
%在explode()中无需转义，explode('\%', $s)反而会匹配字面反斜杠加百分号，错 - 若字符串来自
$_GET或file_get_contents()读 URL 内容，大概率已被 PHP 自动 decode（取决于 SAPI），也可能没被 decode——别假设，用rawurldecode($s) === $s检查是否原始编码态
需要保留 URL 编码完整性时，别用 explode()
当字段本身含 %xx 编码（比如日志行、HTTP 请求体片段），又想按独立的分隔符 % 切（例如协议自定义格式 "key1%value1%key2%value2"），必须避开编码内的 %。
- 用
preg_split()配合负向先行断言：preg_split('/%(?![0-9A-Fa-f]{2})/', $s)—— 只在后面**不跟两个十六进制字符**的%处切 - 注意 PCRE 默认不支持 Unicode 字符类，如果编码含 UTF-8 多字节（如
%E6%96%87），该正则仍有效，因它只检查 ASCII 十六进制字符 - 性能上比
explode()略低，但对千字符内字符串几乎无感；若高频调用，可预编译正则：static $pattern = '/%(?![0-9A-Fa-f]{2})/'; - 别用
urldecode()先全解再切——可能把合法业务字段（如值含空格）破坏，且无法还原原始编码格式
% 出现在正则或 printf 场景下才需转义
标题里提到“转义”，容易误导。在 explode() 中 % 就是普通字符，根本不用转；真正要转义的场景是：
立即学习“PHP免费学习笔记（深入）”；
-
sprintf()或printf()：写"%d%%"才能得到"42%"，第一个%是格式符起始，第二个%是字面百分号 -
preg_replace()等正则函数：若你在模式里写/%/，没问题；但若写成/\%/，PCRE 会警告「未知转义 \%」，实际行为等价于/%/，纯属冗余 - Shell 命令拼接（如
exec("echo $str")）：此时%一般无特殊含义，但若混入date命令等上下文，才需考虑 shell 层转义——这和 PHP 字符串分割无关
调试时快速验证 % 是否被意外修改
最常踩的坑不是代码写错，而是数据源头已变形。执行前加一行诊断：
var_dump(bin2hex($str));
看输出里 % 对应的字节是不是 25（ASCII）。如果不是，说明之前某步（如 urldecode()、iconv()、数据库驱动自动转换）已把它吃掉或替换成其他字符。
另一个信号：用 mb_strlen($str, '8bit') 和 strlen($str) 对比，若不等，说明存在多字节字符，而你用单字节函数（如 strpos()）定位 % 可能偏移——这时应改用 mb_strpos($str, '%', 0, '8bit')。
复杂点永远在输入不可控——别急着改 explode，先盯住那串原始字符串从哪来、中间经过了什么函数、是否被任何扩展（如 mbstring.overload）静默重写。
