vendor目录没生成，基本是当前路径错误、composer.lock缺失或vendor属主为root；需确认pwd在项目根目录、composer.lock存在且非空、vendor归属当前用户，并验证autoload.php可加载。
vendor目录没生成，基本就是当前路径、composer.lock或权限三者之一出问题，不是Composer坏了，也不是网络慢。
确认当前工作目录是不是项目根目录
Composer只认你敲命令时的pwd路径，不识别“项目结构”。常见错误是在src/或public/里执行composer install，结果vendor被建在子目录下，上层脚本require 'vendor/autoload.php'就直接报错。
- 终端里先运行
pwd，确认输出路径包含composer.json - 如果不在根目录，用
cd ..或cd /path/to/project切过去再试 - CI/CD 脚本里必须显式写
cd /project/path && composer install，不能依赖默认路径
检查composer.lock是否存在且有效
composer install的设计就是只按composer.lock还原，没有它就拒绝执行——不会退而求其次去读composer.json。
- 运行
ls -l composer.lock确认文件存在且非空 - 存在就直接跑
composer install，别加--no-dev等参数干扰还原逻辑 - 不存在就别硬试
install，改用composer update（会重算依赖，版本可能变） - 优先从 Git 恢复：
git checkout HEAD -- composer.lock
排查vendor目录权限归属问题
报错里出现Permission denied，大概率不是权限位不够（比如chmod 755），而是vendor/目录属主是root，当前用户无权修改。
- 运行
ls -ld vendor/，如果输出含root root，就确认是所有权问题 - 只修复该目录：
sudo chown -R $USER:$USER vendor/ - 别碰
composer.json或源码目录，除非ls -ld composer.lock也显示root - 修复后立刻跑
composer install --no-scripts测试能否生成基础结构
验证vendor是否真安装成功
别只看有没有报错，要验证 autoload 是否可用、包是否真被解压进来了。最直接的方式是查vendor/autoload.php文件是否存在，且能被require。
- 检查
vendor/autoload.php是否存在，且大小不为0 - 运行
php -r "require 'vendor/autoload.php'; echo 'OK';"，看是否输出OK - 确认
vendor/workerman/workerman/Worker.php存在（Workerman核心类） - 若仍失败，加
-vvv参数重试：composer install --no-cache -vvv，观察实际解压路径和卡点
最容易被忽略的是：即使composer install显示“Installing dependencies”，但vendor目录空空如也，或者只有composer/子目录；这往往是残留锁文件、磁盘满或中断后状态不一致导致的，得清缓存+删vendor+重装，而不是反复重试。
