$_get在cli下始终为空，因其仅由web服务器在http请求解析时自动填充，而cli无url上下文，$argv才承载命令行参数；需用parse_str+urldecode或getopt手动解析。
php 命令行（CLI）本身不解析 $_GET，因为 $_GET 是 Web SAPI（如 apache、FPM）在处理 HTTP 请求时自动填充的超全局变量；CLI SAPI 根本不读取 URL 查询字符串，直接访问 $_GET 永远是空数组。
为什么 $_GET 在 CLI 下始终为空
CLI 模式没有 HTTP 请求上下文，$_GET、$_POST、$_COOKIE 等均不会被自动填充。即使你运行 php script.php?id=123，这个 id=123 会被当作独立命令行参数传入 $argv，而非注入 $_GET。
-
$argv[0]是脚本路径，$argv[1]开始才是用户传入的参数（如"id=123"） -
$_GET仅由 Web 服务器在请求解析阶段写入，CLI 不触发该逻辑 - 试图在 CLI 中依赖
$_GET会导致逻辑断裂或静默失败
如何手动模拟 $_GET 参数解析
最可靠的方式是遍历 $argv，按 key=value 格式解析并写入 $_GET（或更推荐：用独立变量接收）。注意不要直接覆盖 $_GET，除非你明确知道后续代码会读它且无副作用。
- 用
parse_str(implode('&', array_slice($argv, 1)), $_GET)可批量解析形如php test.php a=1 b=2 c=hello%20world的参数 - 但需警惕空格、特殊字符未编码问题——CLI 不做 URL 解码，
%20不会自动转为空格，得先urldecode() - 更健壮的做法是逐个处理：
foreach (array_slice($argv, 1) as $arg) { if (strpos($arg, '=') !== false) { list($k, $v) = explode('=', $arg, 2); $_GET[$k] = urldecode($v); } } - 如果参数含空格（如
name=John Doe），shell 会将其拆成两个参数，必须用引号包裹：php test.php "name=John Doe"
用 getopt() 更规范地处理命令行参数
比起手动解析 key=value 字符串，getopt() 是 PHP 内置的 POSIX 兼容参数解析函数，支持短选项（-a）、长选项（--id=123）、必需/可选参数，也更符合 CLI 工具惯例。
立即学习“PHP免费学习笔记（深入）”；
- 定义规则：
$options = getopt('i:', ['id:']);表示-i和--id都接受值 - 调用方式：
php script.php -i 123或php script.php --id=123 - 结果存于关联数组：
$options['i']或$options['id']，无需手动urldecode - 不兼容带等号的短选项（
-i=123在部分系统不被识别），建议统一用长选项或空格分隔
Web 脚本复用 CLI 时的兼容性要点
如果你的 PHP 文件既要跑在 Web 上又要跑在 CLI 上，并希望统一使用 $_GET，必须显式桥接：
- 加判断：
if (PHP_SAPI === 'cli') { parse_cli_get_args(); } - 避免污染全局：
$_GET在 CLI 下本不存在，直接赋值虽可行，但可能掩盖类型不一致问题；建议封装为get_input('id')函数，内部根据 SAPI 分支读取 - 测试时注意：Web 环境下
$_GET来自 query String，CLI 下来自$argv，二者编码行为不同（Web 自动解码，CLI 不解码），容易在中文或特殊字符上出错
真正麻烦的不是怎么“模拟”，而是忘记 CLI 和 Web 的执行环境本质不同——参数来源、编码处理、生命周期全都不一样。硬塞 $_GET 往往只是掩盖了架构混用的问题。