最稳妥的CLI环境判断需同时满足PHP_SAPI==='cli'、$_SERVER['argv']存在且为数组、realpath(__FILE__)===realpath($_SERVER['SCRIPT_FILENAME'])，以确保是CLI主脚本执行而非被Web引入或参数伪造。
![php系统常量脚本开发：php_sapi与 $ _server[\'argv\']组合判断cli环境【操作】](https://img.php.cn/upload/article/001/503/042/178040252466996.png)
最稳妥的 CLI 环境判断，不是单靠 PHP_SAPI 或 $_SERVER['argv'] 中的某一个，而是用二者组合——既确认 PHP 的运行接口类型，又验证是否为脚本主入口上下文。
为什么不能只用 PHP_SAPI === 'cli'
虽然 PHP_SAPI === 'cli' 在绝大多数命令行场景下成立，但它只说明 PHP 是以 CLI SAPI 加载的，并不保证当前执行流是“直接调用的 CLI 脚本”。例如：
- Web 脚本中
include 'tool.php';，而 tool.php 内部检查PHP_SAPI === 'cli'→ 仍为 true，但实际运行在 Web 请求中 - 某些容器或 CI 环境里，
PHP_SAPI可能被覆盖或未定义（极少数），需降级处理
为什么不能只用 isset($_SERVER['argv'])
$_SERVER['argv'] 在以下情况可能“存在但误导”：
- FastCGI 模式下，部分服务器会把 CGI 参数注入
$_SERVER['argv']，导致 Web 请求中也出现该数组 - CLI 脚本被
require到 Web 上下文后，$_SERVER['argv']仍保留原始值，但已非当前执行入口 - php.ini 中
register_argc_argv = Off（生产环境常见）时，CLI 下$_SERVER['argv']根本不会被注册
推荐组合判断逻辑
真正安全的做法是：先确认 SAPI 类型，再辅以入口校验。典型写法如下：
立即学习“PHP免费学习笔记（深入）”；
if (PHP_SAPI === 'cli' && isset($_SERVER['argv']) && is_array($_SERVER['argv']) && realpath(__FILE__) === realpath($_SERVER['SCRIPT_FILENAME'] ?? '')) {
// ✅ 确认为 CLI 主脚本执行
} else {
// ❌ 非 CLI 入口：可能是 Web 调用、被 include、或 argv 不可用
}
其中关键点：
-
PHP_SAPI === 'cli'锁定底层运行模式 -
isset($_SERVER['argv']) && is_array(...)排除 php.ini 关闭参数注册的情况 -
realpath(__FILE__) === realpath($_SERVER['SCRIPT_FILENAME'])确保当前文件就是被直接执行的脚本，而非被其他脚本引入
生产环境兼容写法（含降级）
为应对极端情况（如常量未定义、$_SERVER['SCRIPT_FILENAME'] 缺失），可稍作增强：
$sapi = defined('PHP_SAPI') ? PHP_SAPI : php_sapi_name();
$is_cli = ($sapi === 'cli')
&& isset($_SERVER['argv'])
&& is_array($_SERVER['argv'])
&& (!empty($_SERVER['SCRIPT_FILENAME'])
? realpath(__FILE__) === realpath($_SERVER['SCRIPT_FILENAME'])
: true // SCRIPT_FILENAME 不可用时，仅依赖 SAPI + argv 存在性
);
这样既保持简洁，又兼顾 Docker、CI、精简容器等边缘场景。
