最稳妥的CLI环境判断需同时满足PHP_SAPI==='cli'、$_SERVER['argv']存在且为数组、realpath(__FILE__)===realpath($_SERVER['SCRIPT_FILENAME'])，以确保是CLI主脚本执行而非被Web引入或参数伪造。

最稳妥的 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 类型，再辅以入口校验。典型写法如下：

1. if (PHP_SAPI === 'cli' && isset($_SERVER['argv']) && is_array($_SERVER['argv']) && realpath(__FILE__) === realpath($_SERVER['SCRIPT_FILENAME'] ?? '')) { 
2.     // ✅ 确认为 CLI 主脚本执行 
3. } else { 
4.     // ❌ 非 CLI 入口：可能是 Web 调用、被 include、或 argv 不可用 
5. } 

其中关键点：

PHP_SAPI === 'cli' 锁定底层运行模式

isset($_SERVER['argv']) && is_array(...) 排除 php.ini 关闭参数注册的情况

realpath(__FILE__) === realpath($_SERVER['SCRIPT_FILENAME']) 确保当前文件就是被直接执行的脚本，而非被其他脚本引入

生产环境兼容写法（含降级）

为应对极端情况（如常量未定义、$_SERVER['SCRIPT_FILENAME'] 缺失），可稍作增强：

1. $sapi = defined('PHP_SAPI') ? PHP_SAPI : php_sapi_name(); 
2. $is_cli = ($sapi === 'cli')  
3.     && isset($_SERVER['argv'])  
4.     && is_array($_SERVER['argv'])  
5.     && (!emptyempty($_SERVER['SCRIPT_FILENAME'])  
6.         ? realpath(__FILE__) === realpath($_SERVER['SCRIPT_FILENAME'])  
7.         : true // SCRIPT_FILENAME 不可用时，仅依赖 SAPI + argv 存在性 
8.     ); 

这样既保持简洁，又兼顾 Docker、CI、精简容器等边缘场景。

Tags: PHP_SAPI $ _SERVER[‘argv’]

分享到：