parse_str不自动URL解码且不处理深层嵌套，需手动urldecode并避免重复解码；它仅支持一级数组语法，不触发全局变量注入，但无参数调用会引发变量污染风险。
parse_str 是 PHP 里用来把 URL 查询字符串（比如 "name=John&age=30"）转成变量或数组的函数，但它不是万能的“URL 参数解析器”——它不自动解码 URL 编码，也不处理嵌套结构，用错地方会丢数据、覆盖变量甚至引发安全问题。
为什么 parse_str 解析中文或特殊字符会出乱码？
因为 parse_str 默认不做 urldecode，遇到 %E4%BD%A0%E5%A5%BD 这类编码会原样当变量值存进去，变成乱码字符串。
- 必须手动先
urldecode再传给parse_str，或者用parse_str(urldecode($str), $output) - 如果原始字符串来自
$_SERVER['QUERY_STRING']，它通常已解码过，但来自日志、API 请求体或拼接字符串时大概率未解码 - 注意：重复调用
urldecode可能导致双解码错误（如%2520→%20→ 空格），建议只解一次且确认来源状态
parse_str 和 $_GET 的行为差异在哪？
$_GET 是 PHP 在请求进入时就完成了解码 + 解析 + 类型弱转换（数字字符串可能变 int），而 parse_str 是纯字符串到数组映射，不做类型推测，也不过滤空格或 null 字节。
-
parse_str("a=1&b=2+3", $arr)中$arr['b']是"2 3"（+ 被当空格），$_GET同样如此，但你得自己处理 -
parse_str("x=&y=0")得到['x' => '', 'y' => '0']，不会像$_GET那样对空值做额外归一化 - 它不触发
auto_globals_jit或register_globals（已废弃），所以不会污染全局作用域，除非你显式写parse_str($str)不带第二个参数
如何安全地解析带数组语法的查询字符串（如 a[]=1&a[]=2&b[c]=d）？
parse_str 原生支持方括号语法，但只到一级嵌套；深层嵌套（如 b[c][d]=e）会被截断或扁平化，不能直接生成多维数组。
立即学习“PHP免费学习笔记（深入）”；
- 简单场景（
a[]=1&a[]=2）→ 自动转成['a' => [1, 2]]，没问题 - 带键名（
a[0]=1&a[1]=2）也支持，但注意键名若含非数字字符（如a[key]=val），PHP 会把它当字符串键处理 - 嵌套过深（
x[y][z]=1）在 PHP 8.1+ 才开始有限支持，旧版本会忽略第二对方括号，结果是['x' => ['y' => '1']]，而非预期的三维结构 - 更可靠的方式是用
parse_url($url, PHP_URL_QUERY)提取 query 部分，再交给parse_str，避免混淆路径与参数
真正容易被忽略的是：如果你在循环里反复调用 parse_str($str)（没传第二个参数），它会把结果注入当前作用域，变量名来自字符串本身——这等于执行了不可信输入的变量声明，等同于 eval 风险。哪怕只是调试，也务必加第二个参数接收结果。
