答案是必须先执行 composer install --no-dev --optimize-autoloader 再用系统命令打包，因为 composer archive 命令不存在且不生成 vendor/autoload.php；它仅归档源码，无法直接运行。
必须用 composer install --no-dev --optimize-autoloader 生成可部署包
直接 composer archive 打出来的 zip 解压后根本跑不起来——它不生成 vendor/autoload.php，也不触发自动加载优化，更不会安装依赖。真要归档，得先清掉本地 vendor/，再执行完整安装流程。
-
rm -rf vendor/（确保干净起点） -
composer install --no-dev --optimize-autoloader --prefer-dist（关键：--no-dev排除测试工具，--optimize-autoloader生成 classmap，--prefer-dist加速下载） - 此时
vendor/才是生产可用状态，再配合git archive或系统zip打包源码
漏掉 --optimize-autoloader 会导致 autoloader 性能下降 3–5 倍；没加 --no-dev 则可能把 PHPUnit、PHPStan 打进线上镜像，徒增体积和攻击面。
Git tag 必须带 v 前缀且推送到远程
Packagist 不认 1.2.0、release/1.2 或 main，只认 v1.2.0 这类语义化标签。打完不推，Packagist 就永远看不到新版本。
- 打标签：
git tag v1.2.0 -m "Release stable version" - 推送单个标签：
git push origin v1.2.0（不是git push --tags，后者可能带出 dev 分支标签） - 验证是否生效：访问 Packagist 页面，看
Last updated时间是否刷新
如果 composer require myorg/my-pkg 报 Could not find package，90% 是因为没打 v 标签，或打了没推，或 webhook 没配好（Payload URL 必须是 https://packagist.org/api/github）。
私有包发布必须走 Satis 或 Private Packagist，禁用 repositories.type: vcs 直连
开发时临时加 "type": "vcs" 指向内部 Git 仓库看似方便，但上线后会暴露内网地址、绕过权限控制、破坏构建可重现性。企业级流程里，私有包必须经由统一仓库中转。
- Satis 需配置
archive.skip-dev: true和homepage，否则生成的 dist 包无法被安全拉取 - 所有项目
composer.json中repositories只允许出现私有仓库 URL（如https://packages.internal/repo.json），禁止写 GitHub/GitLab 内网地址 - CI 构建时强制加
--repository-url参数，避免开发者本地配置污染构建环境
直连 VCS 的最大风险是：某天 Git 服务器维护停机，所有 CI 构建全挂；而 Satis 或 Private Packagist 具备缓存与镜像能力，能扛住源站故障。
归档前必须校验 platform 与 lock 文件一致性
composer.lock 里记录的依赖版本，可能隐式要求 PHP 8.2，但线上服务器只有 PHP 8.1 —— 这种 mismatch 在归档打包阶段就该暴露，而不是等到线上 composer install 失败才报错。
- CI 中加入检查：
composer validate --strict（报 stability、platform、schema 错误） - 运行
composer config platform.php 8.1显式锁死目标 PHP 版本，让 Composer 提前拒绝不兼容依赖 - 归档脚本里加一步：
php -v | grep "8.1" || exit 1，防止用错 PHP 版本执行安装
最容易被忽略的是 config.platform —— 它不改变本地开发体验，却决定线上能否构建成功。不设它，等于把兼容性赌在开发者口头约定上。
