Composer install 找不到 vendor 包是因为 Git 忽略 vendor/ 且未运行过 install 或删除了它；根本原因是 composer.lock 未提交或不一致，导致依赖无法按预期还原。

为什么 composer install 会找不到已提交的 vendor 包？

因为 Git 忽略了 vendor/，而你本地没运行过 composer install 或删掉了它——这本身不是 Composer 的问题，是版本管理策略和协作流程没对齐。Composer 从不把依赖包塞进 Git，它只靠 composer.lock 还原环境。

确保 composer.lock 被提交且内容可信

composer.lock 是还原依赖的唯一权威依据，但它必须被 git add 并推送到远端。常见错误是：开发者本地改了 composer.json 却忘了生成/提交新的 lock 文件，导致别人拉代码后执行 composer install 拿到的是旧依赖或报错。

github-image-hosting

将图片上传至 img402.dev，以便嵌入 GitHub PR、Issue 和评论中。免费套餐（最大 1MB，保留 7 天，无需身份验证）为默认选项；付费套餐支持最大 5MB，并可通过 x402 实现 1 年（

composer.lock 是还原依赖的唯一权威依据，但它必须被 git add 并推送到远端。常见错误是：开发者本地改了 composer.json 却忘了生成/提交新的 lock 文件，导致别人拉代码后执行 composer install 拿到的是旧依赖或报错。

.01）或永久（）保留。当智能体需要在 GitHub 场景中分享图片时使用——例如截图、原型图、流程图，或其他任何视觉内容。触发条件包括：“截图当前页面”、“附加一张图片”、“将截图添加到该 PR 中”、“上传此原型图”，或任何生成需用于 GitHub 的图片的任务。

下载

• composer install 只读 composer.lock，不读 composer.json 的版本范围（除非 lock 缺失）
• CI/CD 或新成员首次构建时，若 lock 文件缺失或损坏，install 会退化为 update 行为，结果不可控
• 检查 lock 文件是否真实反映当前依赖：运行 composer show --outdated，再比对 composer.lock 里对应包的 version 和 source/reference

Git 忽略 vendor/ 后，怎么让 CI 或同事快速重建？

靠标准化命令流 + 明确的环境假设。不是“怎么绕过忽略”，而是接受忽略、用对命令。

• CI 脚本必须包含：composer install --no-interaction --prefer-dist --optimize-autoloader
• --prefer-dist 强制走压缩包而非 Git 克隆，避免因私有仓库权限、SSH 配置或网络策略失败
• --optimize-autoloader 在生产环境必需，否则类自动加载慢，且可能触发未声明的 dev 依赖加载
• 禁止在项目根目录写 .gitignore 规则去“取消忽略 vendor”——那等于把二进制依赖纳入 Git，迟早出事

遇到 Package X not found 错误时优先排查什么？

这类报错几乎从不因为 vendor/ 被忽略，而是锁文件、源配置或网络三者之一断了链。

• 先确认 composer.lock 是否存在且格式合法（JSON 解析不报错）
• 检查 repositories 配置：私有包源是否在 composer.json 中正确定义？是否需要 auth.json？
• 运行 composer diagnose，它会指出常见陷阱，比如 allow-plugins 拒绝了必要插件、PHP 版本不匹配、或 dist URL 返回 404
• 别急着删 vendor/ 和 lock 重来——先用 composer why-not vendor/package:1.2.3 看冲突源头

Git 忽略 vendor/ 是正确做法，但它的代价是：所有人必须严格依赖 composer.lock 的完整性，以及所有环境都得能访问到 lock 文件里记录的每个包源。这点一旦松动，问题就不是“丢文件”，而是“每次还原都不一样”。