结论：git archive 是最干净可靠的不带 vendor 发布方式；composer archive 因默认排除 composer.lock、不读 .gitignore、语义模糊，绝大多数场景易出错，不应作主力。
直接说结论：脱离 vendor 的发布，不是“打包项目”，而是“只打包源码 + 让接收方自己装依赖”——git archive 是最干净、最可靠的方式；composer archive 在绝大多数场景下反而容易出错，别用它当主力。
为什么 composer archive 不适合“不带 vendor 的发布”
composer archive 的行为取决于当前目录有没有 vendor/，而且它默认会把 composer.lock 排除在外（除非你显式配置），更不会读 .gitignore。结果往往是：你想要轻量源码包，它却塞进一堆 tests/、docs/、.env.example，甚至漏掉 composer.lock 导致接收方装错版本。
- 它只按
autoload和include-path打包（比如只打src/），但你的配置文件、路由定义、迁移脚本往往不在 autoload 范围里，一打就丢 - 如果你本地有
vendor/，composer archive仍不会包含它，但也不会警告你“你没传依赖”——它假装自己只是个源码工具，其实语义模糊 - 想带上
composer.lock？得在composer.json里写"archive": {"exclude": []}再加"extra": {"archive-includes": ["composer.lock"]}，稍有拼写错误就失效
git archive 是真正开箱即用的方案
只要你的项目用 Git 管理，且 .gitignore 里写了 vendor/、node_modules/、.env 等，git archive 就天然满足“只打被跟踪的源码”这个需求——不用改配置、不依赖 Composer 状态、不关心 lock 文件是否存在。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 命令简单：
git archive --format=zip --output=myapp-1.2.0.zip HEAD - 生成的 zip 解压后结构干净：只有 Git 提交过的文件，
composer.json和composer.lock都在（前提是它们已提交） - 接收方拿到后，只需运行
composer install --no-dev --prefer-dist即可，和标准流程完全一致 - CI 中可结合 tag 使用：
git archive --format=tar.gz --output=dist/myapp-$(git describe --tags).tar.gz HEAD
如果必须用 composer archive，怎么勉强让它可用
仅限两种情况：项目没上 Git；或 CI 流程强制要求走 Composer 工具链。这时要绕过它的默认逻辑，手动补全缺失项。
- 确保
composer.json中明确声明需要打包的路径："extra": {"archive-includes": ["config/", "migrations/", "routes/", "composer.json", "composer.lock"]} - 禁用默认排除：
"archive": {"exclude": []}，否则.env.example这类关键文件也会被砍掉 - 执行前先清理无用文件：
rm -rf vendor/ && git clean -fdx，避免残留文件污染归档 - 验证输出：
unzip -l myapp-1.2.0.zip | grep -E "(composer\.lock|src/|config/)";确认关键路径存在
真正麻烦的从来不是打包动作本身，而是“谁来保证 composer.lock 里的版本能在目标环境装得通”。哪怕 zip 生成成功，如果目标机 PHP 版本低于 platform 声明，或者缺了 ext-intl，composer install 仍会失败——这一步没法靠打包规避，只能靠提前约定环境基线。
