答案是报错路径即问题目录，需用ls -ld检查归属，再用sudo chown -R $USER:$USER修复；vendor/、composer.lock或全局缓存目录属主为root即确认所有权错配，禁用chmod -R 777。
报错路径就是你要查的目录
Composer 报 Permission denied 时，错误信息里明确写出的路径（比如 /home/alex/myapp/vendor/autoload.php 或 /var/www/myapp/composer.lock），就是所有权出问题的地方。别猜，直接去查它。
执行：
ls -ld /path/from/error
看输出最左边一列的用户和组名。如果显示 root 而不是你当前用户名（比如 alex），就确认是归属错配。
- 常见出问题的位置：
vendor/、composer.lock、~/.composer/、~/.cache/composer/、$(composer config --global cache-dir) - 嵌套权限混乱很隐蔽：一次
sudo composer install可能让vendor/下个别子目录属主变成root，用ls -la vendor/ | head -10扫一眼就能发现
用 ls -ld 快速定位三类关键路径
别等报错再动，日常排查或部署后顺手跑这三行，覆盖 95% 的权限归属问题：
ls -ld vendor composer.lock
ls -ld $(composer config --global home) 2>/dev/null || echo "global home not set"
ls -ld $(composer config --global cache-dir) 2>/dev/null || echo "cache dir not set"
只要其中任一输出含 root，基本就是它了。
-
composer config --global home默认是~/.composer，但若输出/root/.composer或/var/www/.composer，说明环境已被污染，需重置 - 全局 bin 目录（
composer config --global bin-dir）若指向/usr/local/bin且属主为root，不要硬改权限，应换到~/.local/bin
chown 修复所有权，但别乱用 -R
确认问题路径后，用 chown 改回当前用户即可。核心原则：只修归属，不碰权限位；谁报错修谁，不无脑递归。
- 安全写法（推荐）：
sudo chown -R $USER:$USER vendor
——仅当vendor/确实全是你自己的，且不含软链到系统路径 - 更稳妥做法（尤其 CI 或多人协作项目）：
rm -rf vendor composer.lock && composer install
，从头重建，避免残留 root 子目录 - 禁用
chmod -R 777：它不解决根本问题，反而引入安全风险；Permission denied几乎从来不是因为缺w位，而是属主不对
composer diagnose 会主动提示权限问题
运行 composer diagnose 是最快的方式之一。它会检查 vendor/、缓存目录、临时路径的可写性，并在输出末尾明确标出：
Checking permissions on ./vendor: OK Checking permissions on /home/alex/.cache/composer: FAIL
注意它说的 “FAIL” 后面跟的路径，就是你要立刻 ls -ld 的对象。
- 该命令还会提醒你是否以
root身份运行过 Composer，这是后续权限混乱的根源 - 它不自动修复，但能帮你跳过手动逐个猜测的过程，尤其适合部署脚本中前置校验
实际修复中最容易被忽略的点是：**一次 sudo composer install 可能只污染部分子目录，表面 ls -ld vendor 显示归属正常，但里面某个 vendor/symfony/console 却是 root。必须进到 vendor 里再扫一眼。**
