FrankenPHP 打包后的二进制文件仅用于运行内置 HTTP 应用，不支持执行外部 PHP 脚本或 CLI 参数；命令行任务应使用系统 php 独立运行，或通过 Phar 手动打包 CLI 工具。
FrankenPHP 打包后的应用（即通过 frankenphp pack 生成的单文件二进制）本身不直接支持像传统 PHP CLI 那样运行任意脚本文件（如 php script.php），因为它不是 PHP 解释器的封装，而是将应用逻辑与 FrankenPHP 运行时静态链接后构建的可执行程序。你不能用它去“执行外部 PHP 脚本”——它只运行自己打包进去的那套应用。
为什么 ./myapp 不能当 php 用？
FrankenPHP 的打包机制本质是：把你的 PHP 应用（含 index.php 或 public/ 入口）、路由规则、静态文件、以及 FrankenPHP 自带的 SAPI 运行时，全部编译进一个二进制。它启动后默认监听 HTTP 请求，没有暴露 CLI 解释器接口。
所以你执行 ./myapp --help 或 ./myapp script.php 会失败——这不是设计目标，也无对应参数支持。
常见错误现象：
立即学习“PHP免费学习笔记（深入）”；
./myapp: unrecognized option '--version'-
./myapp some.php: command not found（其实是二进制不识别该用法） - 试图传入
-r、-l等 PHP CLI 参数，直接报错或静默忽略
想在 FrankenPHP 项目里跑命令行任务，得另起炉灶
正确做法是：保持 FrankenPHP 二进制专用于 HTTP 服务；另写独立的 PHP CLI 脚本，用系统已安装的 php 命令运行它们。两者共存不冲突，且更清晰可控。
实操建议：
- 把命令行脚本（如
bin/migrate.php、bin/cleanup.php）放在项目根目录下，**不打包进 FrankenPHP 二进制** - 确保这些脚本开头有
#!/usr/bin/env php，并设好执行权限：chmod +x bin/migrate.php - 脚本内可通过
require __DIR__.'/vendor/autoload.php';加载项目依赖（Composer autoloader 必须可用） - 若需共享配置（如数据库连接），建议把配置提取为独立 PHP 文件（如
config/cli.php），避免硬编码或依赖$_SERVER环境 - 不要在 CLI 脚本里调用
$_SERVER['REQUEST_URI']或依赖 HTTP 上下文，否则会出错
如果真要“打包进二进制”的 CLI 工具，只能手动嵌入
FrankenPHP 官方不提供 CLI 模式打包支持，但你可以绕过它，用标准 PHP + Phar 实现类似效果：
- 写一个 CLI 入口脚本（如
cli.php），用getopt()或Symfony Console解析参数 - 用
Phar::buildFromDirectory()把它和依赖打包成tool.phar - 设置 stub 并加可执行权限：
chmod +x tool.phar - 这样得到的
tool.phar可以像./myapp一样双击或./tool.phar migrate运行，但它和 FrankenPHP 二进制完全无关 - 注意：Phar 需开启
phar.readonly = Off（CLI 模式下通常默认关闭），否则无法动态加载
真正容易被忽略的一点：FrankenPHP 打包产物是面向 HTTP 服务的终态交付物，不是通用 PHP 运行环境替代品。混淆这两者，会在调试、日志、错误追踪阶段付出额外成本——比如 CLI 脚本里的 var_dump() 输出被 FrankenPHP 的 HTTP 日志框架吞掉，或者信号处理（SIGINT）行为不一致。
