删 vendor 后应执行 composer install 而非 update，因 install 严格按 composer.lock 锁定的版本、哈希和源地址重建 vendor，确保环境一致；update 会重算依赖并升级版本，破坏确定性。
删了 vendor 目录后，直接 composer install 就行
只要 composer.json 和 composer.lock 都还在，composer install 就能完全重建 vendor 目录，和原来一模一样。它不读网络最新版，只按 lock 文件里锁定的版本、哈希、源地址来装。
常见错误现象：
– 误用 composer update：会升级所有包（或指定包），改写 lock 文件，导致行为不可控
– 删除后运行 composer require xxx：只装新包，旧依赖全丢，vendor 不完整
- 确认
composer.lock存在且未被修改（Git 可用git status快速检查） - 执行前清掉残留的
vendor和composer.lock.bak等临时文件，避免干扰 - 如果项目用了私有仓库或认证，确保
auth.json在家目录或项目根目录下，否则可能卡在某个包拉取失败
composer install 报 “Your requirements could not be resolved”
这通常不是命令错了，而是 composer.lock 和 composer.json 对不上，或者 lock 文件本身已损坏。
使用场景：
– Git 切分支后忘记 composer install，直接跑应用报错
– 手动改过 composer.json 但没更新 lock，又删了 vendor
- 先运行
composer validate：检查json和lock是否语法合法、结构匹配 - 如果 validate 失败，优先修复
composer.json（比如多余逗号、字段拼错） - 如果 validate 通过但 install 仍失败，大概率是
lock文件过期或混入了不兼容条目，可删掉composer.lock，再跑composer install—— 这会生成新 lock，但注意：这等价于一次update，版本会变
为什么不用 composer update 恢复 vendor
composer update 的本质是重新解析依赖树、找满足约束的最新可用版本，再写进 lock。它不是“恢复”，而是“升级+重算”。你失去的是确定性。
性能 / 兼容性影响：
– 网络耗时更长（要查 packagist 或私仓元数据）
– 可能引入 BC break：比如 monolog/monolog 从 2.9 升到 3.0，接口变了，代码直接报 Class not found 或方法不存在
– CI/CD 中若用 update，不同时间构建结果不一致，排查问题成本飙升
- 团队协作中，
lock文件必须提交 Git，它是环境一致性的锚点 - CI 脚本里应固定用
composer install --no-interaction --prefer-dist，禁掉交互、加速下载 - 本地开发想试新版？可以
composer update xxx --with-dependencies，但别碰整个树
vendor 目录权限或符号链接出问题
尤其在 Docker、Windows WSL、Mac M1 混合环境下，vendor 重建后可能出现 Class 'XXX' not found，但文件明明存在 —— 很可能是 autoload 机制失效，根源常是路径或权限。
常见错误现象：
– composer dump-autoload 后仍报找不到类
– vendor/autoload.php 被包含，但 PSR-4 映射路径没生效
– 使用 composer install --no-scripts 跳过了自动生成 autoload 的步骤
- 删掉
vendor/autoload.php和vendor/composer/autoload_*.php，再跑composer install，强制重生成 - 检查
composer.json里"autoload"段是否指向真实存在的目录，比如"App\": "src/"，而项目里实际是app/ - Docker 中挂载
vendor目录是危险操作，会导致宿主机与容器内文件状态不一致，应让composer install在容器内执行，不挂载vendor
composer.lock，它比记忆可靠。 
