PHP CLI 魔法：3种从命令行带参数运行Web脚本的实用方法

## 问题背景 在日常开发中，我们经常会遇到这样的需求：一个已经在 Web 环境下正常工作的 PHP 控制器方法，现在需要通过 `Crontab` 定时执行。例如，一个用于每日统计数据的功能。 Web 请求的 URL 可能是这样的： `http://lib00.com/statistics/daily-pv-cal?date=2025-10-30` 控制器代码依赖 `$_GET['date']` 来获取日期参数： ```php // php_app/Controllers/Backend/StatisticsController.php class StatisticsController { /** * 每日 PV 统计（增量更新） * Crontab: 10 0 * * * */ public function dailyPVCal(): void { set_time_limit(600); ini_set('memory_limit', '512M'); // 核心问题：CLI 模式下如何获取 'date' 参数？ $statDate = $_GET['date'] ?? date('Y-m-d', strtotime('-1 day')); // ...业务逻辑... } } ``` 入口文件 `index.php` 已经做了简单的 CLI 模式判断，但尚未处理参数传递： ```php // php_app/public_backend/index.php <?php // 检测 CLI 模式 if (php_sapi_name() === 'cli') { // 模拟 HTTP 环境 $_SERVER['REQUEST_METHOD'] = 'GET'; $_SERVER['REQUEST_URI'] = $argv[1] ?? '/sitemap/generate'; // $argv[1] 是脚本后的第一个参数 $_SERVER['HTTP_HOST'] = 'wiki.lib00.com'; // 使用 wiki.lib00.com 作为标识 } // ...框架加载逻辑... ``` 核心挑战是：如何在 CLI 模式下，优雅地将参数（如 `date=2025-10-30`）传递给脚本，并让 `StatisticsController` 中的 `$_GET['date']` 能正确接收到值，而无需修改控制器本身的逻辑？ 下面是由 DP@lib00 整理的三种行之有效的解决方案。 --- ## 解决方案 ### 方案一：模拟完整请求 URI (推荐) 这是最简单、最直观的方法，因为它最接近原始的 HTTP 请求方式，对现有代码的侵入性最小。 **修改 `index.php`:** 在模拟环境的代码块中，增加对 `REQUEST_URI` 中查询字符串的解析。 ```php // php_app/public_backend/index.php if (php_sapi_name() === 'cli') { $_SERVER['REQUEST_METHOD'] = 'GET'; $_SERVER['REQUEST_URI'] = $argv[1] ?? '/sitemap/generate'; $_SERVER['HTTP_HOST'] = 'wiki.lib00.com'; // 新增：解析 URL 中的查询字符串并填充到 $_GET $urlParts = parse_url($_SERVER['REQUEST_URI']); if (isset($urlParts['query'])) { parse_str($urlParts['query'], $_GET); } } ``` **命令行调用：** 将完整的 URI 路径（包括查询参数）作为一个字符串参数传递。注意，如果 URI 包含 `&` 等特殊字符，最好用引号包裹起来。 ```bash php index.php "/statistics/daily-pv-cal?date=2025-10-30" ``` ### 方案二：使用 `getopt` 解析命名参数 `getopt` 是 PHP 内置的函数，专门用于解析命令行选项，是构建标准 CLI 工具的常用方法。 **修改 `index.php`:** ```php // php_app/public_backend/index.php if (php_sapi_name() === 'cli') { // 解析命令行参数，如 --uri=... --date=... $options = getopt('', ['uri::', 'date::']); $_SERVER['REQUEST_METHOD'] = 'GET'; $_SERVER['REQUEST_URI'] = $options['uri'] ?? $argv[1] ?? '/sitemap/generate'; $_SERVER['HTTP_HOST'] = 'wiki.lib00.com'; // 将命令行参数转换为 $_GET if (isset($options['date'])) { $_GET['date'] = $options['date']; } // 可以扩展支持更多参数 } ``` **命令行调用：** 这种方式更加清晰，参数和值一目了然。 ```bash php index.php --uri=/statistics/daily-pv-cal --date=2025-10-30 ``` ### 方案三：手动解析 `$argv` 这是一种更灵活但相对原始的方法，通过遍历 `$argv` 数组来手动解析 `key=value` 格式的参数。 **修改 `index.php`:** ```php // php_app/public_backend/index.php if (php_sapi_name() === 'cli') { $_SERVER['REQUEST_METHOD'] = 'GET'; $_SERVER['REQUEST_URI'] = $argv[1] ?? '/sitemap/generate'; $_SERVER['HTTP_HOST'] = 'wiki.lib00.com'; // 从 $argv[2] 开始解析 key=value 格式的参数 for ($i = 2; $i < count($argv); $i++) { if (strpos($argv[$i], '=') !== false) { list($key, $value) = explode('=', $argv[$i], 2); $_GET[trim($key)] = $value; } } } ``` **命令行调用：** 每个 `key=value` 对都是一个独立的参数。 ```bash php index.php /statistics/daily-pv-cal date=2025-10-30 ``` --- ## Crontab 集成示例 以推荐的方案一为例，可以这样配置你的 `Crontab` 任务。 ```cron # 每天凌晨 0:10 执行，统计前一天的数据 # 注意：在 crontab 中 '%' 需要转义成 '\%' 10 0 * * * cd /path/to/wiki.lib00/php_app/public_backend && php index.php "/statistics/daily-pv-cal?date=$(date -d 'yesterday' +\%Y-\%m-\%d)" >> /var/log/daily-pv.log 2>&1 ``` 如果你的 PHP 脚本本身就有处理默认日期的逻辑（如 `date('Y-m-d', strtotime('-1 day'))`），也可以不传 `date` 参数： ```cron 10 0 * * * cd /path/to/wiki.lib00/php_app/public_backend && php index.php "/statistics/daily-pv-cal" >> /var/log/daily-pv.log 2>&1 ``` --- ## 优化建议 为了方便调试和监控，建议在你的控制器方法中增加对 CLI 环境的判断，并输出相应的日志信息。 ```php // php_app/Controllers/Backend/StatisticsController.php public function dailyPVCal(): void { // ... $statDate = $_GET['date'] ?? date('Y-m-d', strtotime('-1 day')); // 在 CLI 模式下输出日志，方便追踪 if (php_sapi_name() === 'cli') { echo "[" . date('Y-m-d H:i:s') . "] Starting statistics for: {$statDate}\n"; } // ... 业务逻辑 ... if (php_sapi_name() === 'cli') { echo "[" . date('Y-m-d H:i:s') . "] Statistics completed.\n"; } } ``` --- ## 总结 将 Web 脚本用于 CLI 自动化任务是常见的需求。通过在入口文件处巧妙地模拟 HTTP 环境并解析命令行参数，我们可以轻松复用现有的业务逻辑代码。在本文介绍的三种方法中，**方案一（模拟完整请求 URI）** 因其简单和低侵入性，是大多数场景下的首选方案。