Composer install 不支持直接用本地 Git 仓库还原 vendor；它默认按 composer.lock 精确校准已存在包，版本或哈希不符则删除重装，而非跳过。
Composer install 时如何跳过远程包拉取，直接用本地 Git 仓库还原 vendor
Composer 本身不提供“回滚到某次 composer install 状态”的内置命令，但如果你的项目 vendor 目录曾被 Git 跟踪（或你有备份），最可靠、最快的恢复方式是放弃重装，直接用 Git 检出历史快照——前提是 vendor 确实提交过。
常见错误现象：composer install 卡在某个包下载失败、composer update 引入了不兼容版本导致运行报错、CI 构建因网络问题中断后想秒级复原。
- 只在
vendor曾被git add vendor并提交过的项目中有效；纯忽略vendor的标准做法下此法不适用 - Git 必须保留完整历史（不能
git push --force覆盖掉关键 commit） - 检出前需确认当前
composer.lock与目标vendor快照匹配，否则类加载或符号解析会失败
如何安全地把 vendor 加进 Git（仅限私有/离线环境）
这不是推荐做法，但在内网、无 Packagist 镜像、或对部署一致性要求极高的场景下，它是唯一能实现“原子级回滚”的方案。关键不是“能不能加”，而是“怎么加才不破坏 Composer 工作流”。
- 必须在
.gitignore中显式移除/vendor/行，否则git add vendor无效 - 添加时用
git add -f vendor强制加入（绕过 .gitignore），但仅限首次；后续更新用git add vendor即可 - 每次
composer install或update后，应立即git add composer.lock vendor并提交，形成“锁文件 + 二进制包”配对快照 - 避免混合使用：不要一边
git checkoutvendor，一边又执行composer dump-autoload—— autoloader 生成逻辑可能与检出的文件结构不一致
用 git checkout 还原 vendor 的具体操作链
核心动作就是三步：定位 commit → 清理干扰 → 检出目录。重点在于规避 Git 默认的“不覆盖已修改文件”保护机制。
- 先运行
git status，确保工作区干净；如有未提交变更，要么git stash，要么确认这些变更是否影响 vendor（比如你手动改过某个包的 src） - 用
git log --oneline -n 20 -- vendor查看 vendor 目录的修改历史，挑出目标 commit hash（例如a1b2c3d） - 执行
git checkout a1b2c3d -- vendor（注意双横线--分隔符，防止 Git 把 vendor 当作分支名） - 最后运行
composer dump-autoload（仅当项目启用了 classmap 或 files autoload 且 vendor 内部结构变化时需要）
为什么不用 composer install --no-install && git reset？
有人试图用 git reset --hard 回退整个项目再重装，这看似合理，但实际引入两个隐性风险：
-
composer install依赖当前网络、PHP 扩展、以及 Packagist 响应状态——任一环节异常，就卡住，失去“快速”意义 - 即使安装成功，不同时间点的
composer install可能因镜像缓存、压缩算法微调、或平台差异（如 Windows vs Linux 的 symlink 处理），产出略有不同的vendor文件树，无法保证与历史完全一致 - Git 检出是字节级还原，而 Composer 安装是重建过程；前者是“恢复”，后者是“再生产”
真正容易被忽略的是：vendor 目录一旦被 Git 跟踪，就必须把它当作“构建产物”来管理——每次变更都要同步提交 composer.lock 和 vendor，漏掉任意一个，下次 checkout 就会失配。
