如何通过命令行执行 PHAR 归档中的 PHP 文件

如何通过命令行执行 PHAR 归档中的 PHP 文件

本文详解在 RHEL 7 环境下，如何正确配置 PHAR 归档以支持 Web 访问与命令行独立执行（如定时任务），重点解决 php phar.phar/path/to/script.php 报错“Could not open input file”的根本原因及可靠实践方案。

在 RHEL 7 环境下，很多开发者都遇到过这个头疼的问题：想把应用打包成 PHAR 归档，Web 访问一切正常，但一到命令行调用，比如想通过定时任务执行归档里的某个脚本，系统就毫不留情地抛出“Could not open input file”的错误。这背后的原因，其实并非配置失误，而是 PHAR 本身的设计特性使然。

简单来说，PHAR 归档是一个封装好的文件系统。但关键在于，PHP 解释器并不会自动将类似 `/jobs/test.php` 这样的路径识别为 PHAR 内部的相对路径。当你执行 `php /path/to/phar.phar/jobs/test.php` 时，PHP 会傻傻地在宿主机的真实文件系统里寻找这个路径，结果当然是找不到。所以，这并非 bug，而是一个需要绕过的设计限制。

那么，正确的解决思路是什么？答案是：统一入口 + 路由分发。我们必须放弃“直接调用内部文件”的想法，转而让所有命令行请求都先经过 PHAR 的默认启动脚本（stub），再由这个“总控中心”根据参数去动态加载并执行目标脚本。

✅ 正确做法：双 Stub 分离 + CLI 路由

很多配置只考虑了 Web 场景，使用了 `Phar::webPhar()`，但这对 CLI 模式是无效的。可靠的做法是在构建 PHAR 时，就明确区分 Web 和 CLI 的启动逻辑。核心在于改用 `Phar::setDefaultStub()` 来指定一个专用于命令行的入口。

具体操作上，需要替换掉原来的 `setStub` 部分：

// 构建 PHAR 时关键修改（替换原 setStub 部分）
$phar->setStub($phar->createDefaultStub('cmd/index.php', 'index.php'));
// 注意：第一个参数是 CLI 入口，第二个是 Web 入口（保持 webPhar 兼容性）

接下来，在你的源码目录（例如 `/path/to/files/`）下，需要创建这个 CLI 入口文件 `cmd/index.php`。这个文件将扮演路由器的角色。

立即学习“PHP免费学习笔记（深入）”；

 [script-path]\n";
    exit(1);
}
$command = $argv[1];
if ($command === 'cron' && isset($argv[2])) {
    $targetPath = $argv[2];
    $phar = new Phar(__FILE__);
    // 安全校验：仅允许访问 jobs/ 目录下的 .php 文件
    if (preg_match('/^jobs\/[a-zA-Z0-9_\-\.]+\.php$/', $targetPath)) {
        try {
            // 从 PHAR 中读取并执行（不写入临时文件）
            $code = $phar[$targetPath]->getContent();
            // 注入必要上下文（如 __DIR__、__FILE__ 模拟）
            $code = "getMessage() . "\n";
            exit(1);
        }
    } else {
        echo "Forbidden path: {$targetPath}\n";
        exit(1);
    }
} else {
    echo "Unknown command: {$command}\n";
    exit(1);
}

? 使用方式（Crontab 示例）

配置好之后，在 Crontab 中调用就变得非常清晰和直接了。你不再需要纠结于内部路径，而是通过定义好的命令和参数来执行。

# 每天凌晨 2 点执行 PHAR 内的定时任务
0 2 * * * /usr/bin/php /path/to/phar.phar cron jobs/test.php
# 或显式指定 PHP 解释器（推荐）
0 2 * * * /opt/remi/php82/root/usr/bin/php /path/to/phar.phar cron jobs/cleanup.php

⚠️ 注意事项与最佳实践

方案虽好，但魔鬼藏在细节里。以下几个要点，是确保方案稳定、安全运行的关键：

• 安全性优先：路径白名单校验是生命线。绝对要避免直接使用 `include 'phar://' . __FILE__ . '/' . $_SERVER['argv'][2]` 这种写法，必须严格限制可访问的目录和文件后缀，从根本上杜绝任意文件读取或代码注入的风险。
• eval() 风险提示：上面的示例为了清晰地展示逻辑，使用了 `eval()`。但在生产环境中，这需要格外小心。更稳妥的做法是考虑使用 `Phar::loadPhar()` 配合 `include`，但务必确保目标脚本本身没有语法错误，且不依赖未定义的全局变量。
• 权限与扩展：基础环境要打牢。确保命令行下的 PHP 已启用 phar 扩展（可通过 `php -m | grep phar` 验证），并且 PHAR 文件本身具有可执行权限（执行 `chmod +x phar.phar`）。
• 调试技巧：如果遇到问题，可以在 CLI 入口脚本中临时加入 `var_dump($argv)` 或 `print_r($phar->getMetadata())` 来快速验证参数传递和 PHAR 元数据是否正确加载。

说到底，通过这样一套结构化的设计，PHAR 归档就能真正实现“一包两用”：既可以是便捷的 Web 应用部署包，也能化身轻量级的命令行工具包。这不仅解决了路径解析的陷阱，更实现了跨环境行为的一致性，可谓一举多得。