Composer 不提供打 PHAR 包功能，需用 PHP 的 Phar 扩展手动构建；关键步骤包括：准备入口脚本、生成确定性自动加载映射、排除无关文件、设置 stub 与压缩、签名及权限配置。
Composer 本身不提供打 PHAR 包的功能，它只是一个依赖管理器；真正构建 PHAR 的是 PHP 自带的 Phar 扩展，而 composer install 或 composer dump-autoload 只是为打包做准备——比如生成自动加载器、固化依赖路径。
为什么不能直接用 composer build-phar？
因为这个命令根本不存在。Composer 没有内置 PHAR 构建逻辑，社区也未将其纳入核心功能。有人误以为 composer install --no-dev --optimize-autoloader 就是在“打包”，其实它只是生成更紧凑的 vendor/autoload.php 和 vendor/composer/autoload_*.php，离可执行 PHAR 还差很远。
- PHAR 需要显式创建
Phar对象、添加文件、设置 stub、签名（可选）、压缩（可选） - 入口脚本（如
bin/myapp）必须能被 PHAR 正确识别为 CLI 入口，且不依赖外部vendor/ - 自动加载器需适配 PHAR 环境：
__DIR__在 PHAR 中指向 phar:// 协议路径，硬编码相对路径会失效
如何让 Composer 项目支持 PHAR 打包？
关键不是“用 Composer 打包”，而是“让 Composer 管理的项目能被安全打包进 PHAR”。需要三步准备：
- 确保入口脚本（如
bin/console）以#!/usr/bin/env php开头，并在开头加Phar::mapPhar()和include 'phar://myapp.phar/vendor/autoload.php';（或使用Phar::loadPhar()） - 运行
composer install --no-dev --optimize-autoloader --classmap-authoritative，生成确定性、无反射的自动加载映射 - 在
composer.json中声明"autoload": {"psr-4": {"App\": "src/"}}并执行composer dump-autoload --classmap-authoritative，避免运行时动态查找
否则 PHAR 内部的类加载大概率失败，报错类似：Class "AppConsole" not found 或 require(): phar://xxx.phar/vendor/autoload.php: failed to open stream。
立即学习“PHP免费学习笔记（深入）”；
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
Phar::buildFromDirectory() 常见陷阱
这是最常用但最容易出错的打包方式。它会递归扫描目录并加入所有文件，但默认不处理符号链接、忽略隐藏文件、且不会重写自动加载路径。
- 必须手动排除
.git、tests/、docs/等非运行时所需目录，否则 PHAR 体积暴增且可能引入敏感信息 - 必须调用
$phar->setStub($phar->createDefaultStub('bin/console'))，否则执行php myapp.phar会报Phar: invalid stub - 必须调用
$phar->startBuffering()+$phar->stopBuffering()才能启用压缩和签名；直接buildFromDirectory()后压缩无效 - 若用
gz压缩，PHP 运行时需启用zlib扩展，否则解包失败
示例关键片段：
$phar = new Phar('myapp.phar');
$phar->startBuffering();
$phar->buildFromDirectory('build/', '/.php$/'); // 只加 PHP 文件
$phar->setStub($phar->createDefaultStub('bin/console'));
$phar->compressFiles(Phar::GZ);
$phar->stopBuffering();
PHAR 签名与执行权限问题
没有签名的 PHAR 在某些 PHP 配置下无法执行（phar.readonly=On 是默认值，且不能在运行时修改），而签名又依赖 OpenSSL 私钥——这导致本地测试和 CI 打包行为不一致。
- 开发时可临时设
phar.readonly=Off（php.ini 或php -d phar.readonly=Off script.php），但生产环境必须签名 - 签名后执行仍报
Phar: invalid signature，常见原因是：私钥格式不对（需 PEM）、没调用$phar->setSignatureAlgorithm(Phar::SHA256, $privateKey)、或公钥未通过Phar::getSupportedSignatures()检查 - Linux/macOS 下生成的 PHAR 需
chmod +x myapp.phar才能./myapp.phar直接运行；Windows 用户则必须php myapp.phar
真正麻烦的不是打包动作本身，而是让一个 Composer 项目在脱离 vendor 目录、脱离当前工作目录、甚至脱离原始文件系统结构的前提下，还能正确加载类、读取配置、定位资源——这些路径逻辑往往藏在框架或自定义代码里，不打包到最后一刻根本看不出问题。
