根本原因是目录所有权错配而非权限不足，需用sudo chown -r $user:$user vendor/ composer.lock ~/.composer修复归属，禁用chmod 777和sudo composer install。
报“Permission denied”写 vendor/ 或 composer.lock
根本不是权限不够，而是目录被 root 占过坑——你用 sudo composer install 运行过一次，vendor/ 和 composer.lock 就变成 root 所有，之后普通用户再跑就卡在 file_put_contents(/path/to/vendor/autoload.php): Permission denied。
- 先查归属：
ls -ld vendor/ composer.lock，看到root root就对了 - 别用
chmod 777硬怼，改归属才治本：chown -R $USER:$USER vendor/ composer.lock - 如果
~/.composer也是 root 的，一并修复：chown -R $USER:$USER ~/.composer - 虚拟主机里用户常是
www-data或apache，得确认实际运行用户：ps aux | grep php或看控制面板进程属主
卡在 “Loading composer repositories” 或超时不动
虚拟主机多数没开外网直连，或 DNS 被阉割，packagist.org 解析失败是常态。这时候换镜像、清缓存、验证真实请求路径，三步缺一不可。
- 必须用阿里云 HTTPS 镜像，且结尾带
/：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 配完立刻清缓存：
composer clear-cache，否则旧失败记录还在，重试照样走原地址 - 加
-vvv看真实请求：composer install -vvv 2>&1 | grep -m1 Downloading，输出的 URL 必须是mirrors.aliyun.com才算生效 - 如果仍卡住，手动测镜像可用性：
curl -I https://mirrors.aliyun.com/composer/packages.json，返回HTTP/2 200才可信
报 “Your requirements could not be resolved” 却没改过 composer.json
这不是依赖冲突，是虚拟主机 PHP 环境和 composer.lock 对不上——常见于低配主机只装了 PHP 7.4，但锁文件里某个包要求 PHP >=8.1；或者 ext-mbstring、ext-xml 这类扩展根本没启用。
- 先跑
php -v和php -m | grep -E "(mbstring|xml|curl|zip)"，确认版本和扩展 - 再跑
composer diagnose，它会直接标出缺失扩展或版本越界项 - 检查
composer.json顶部是否有"config": {"platform": {...}}，若写了"php": "8.2"但主机只有 7.4，就得删掉 platform 配置或降级锁文件 - 临时绕过用
--ignore-platform-reqs只能应急，装完大概率php artisan报错或类找不到
执行成功但 autoload 失效、类找不到
composer install 成功不等于能跑，虚拟主机常见问题是 autoloader 没生成或路径映射错位，尤其当 vendor/ 被挪过位置、或项目根目录不在 Web 入口下。
- 确认
vendor/autoload.php存在且可读：ls -l vendor/autoload.php - 检查 Web 入口脚本（如
public/index.php）是否正确 require 它：require __DIR__.'/../vendor/autoload.php';，注意相对路径别写错 - 如果用了自定义 autoloader 或 PSR-4 映射，跑一遍
composer dump-autoload强制重建映射表 - 某些虚拟主机禁用了
symlink()，导致 Composer 自动生成的符号链接失效，可加--no-symlinks重装
composer install -vvv 抓第一行真实请求和最后一行堆栈，比盲目换源或 chmod 有用得多。
