vendor/autoload.php不存在是因composer install未完成，应删掉vendor和composer.lock后重新执行composer install；空文件夹因包无bin配置或安装参数限制，非异常。
composer install 时提示 vendor/autoload.php 不存在怎么办
这不是文件真丢了，而是 composer install 没跑完或中途失败，导致 vendor/ 目录没生成。别急着手动补文件——autoload.php 是自动生成的，手动放进去也没用，还可能和实际依赖不匹配。
实操建议：
- 先确认当前目录下有
composer.json和composer.lock；缺composer.lock就用composer install --no-scripts强制重装（但会丢自定义脚本） - 删掉整个
vendor/目录和composer.lock，再跑composer install——这是最干净的重置方式 - 如果卡在某个包下载慢或超时，加
-vvv看具体哪步挂了，常见是网络问题或私有仓库认证失效
如何快速检查哪些包的文件被意外删了
composer install 默认不校验已安装包的完整性，它只看 composer.lock 里记录的 hash 是否匹配本地文件。所以你删了某个 vendor/foo/bar/src/Helper.php，composer 不会主动报错，直到运行时才 Class not found。
实操建议：
- 用
composer install --dry-run可预览要安装/更新的包，但不校验文件完整性 - 真正能查缺失文件的是
composer check-platform-reqs（只查 PHP 扩展）和第三方工具，比如composer validate只校验composer.json格式，不碰 vendor - 可靠做法：删
vendor/后重新composer install，让所有文件从 lock 文件重建——这才是唯一可信的“完整性验证”
为什么 composer update 后项目反而跑不起来了
因为 composer update 会改 composer.lock，升级包版本，而新版包可能删了旧方法、改了命名空间、甚至要求更高 PHP 版本。你没动代码，但依赖变了。
实操建议：
- 永远优先用
composer install（读 lock 文件），而不是无脑update；CI/部署环境必须禁用update - 升级前先跑
composer outdated看哪些包有更新，再针对性composer update vendor/package，避免全量漂移 - 留意输出里的
Downgrading或Upgrading行——特别是 major 版本号变化（如v2.5.0 → v3.0.0），大概率有 BC break
vendor 目录里一堆空文件夹，是 composer 没装全吗
不是。空文件夹（比如 vendor/bin/ 下什么都没有）通常是因为对应包没声明 bin 配置，或该包的 bin 脚本被 composer install --no-bin-links 跳过了。也可能是你之前用过 --prefer-dist，但某些包只有 --prefer-source 才带 bin 文件。
实操建议：
- 检查该包的
composer.json里有没有"bin"字段，没有就真没可执行文件 - 运行
composer dump-autoload -o并不会修复空目录，它只优化自动加载映射 - 想强制重建所有 bin 链接？删掉
vendor/bin/再跑composer install，前提是包本身支持且没被--no-bin-links屏蔽
composer install 的可靠性完全依赖 composer.lock 是否真实反映当前 vendor 状态——它不校验，只重建。所以别信“应该没少啥”，删了重装才是最快验证方式。 
