报错出现“permission denied”时，90%是因目录属主为root而非当前用户，应先根据错误路径定位vendor/、composer.lock或缓存目录，再用ls -ld确认归属，最后执行sudo chown -r $user:$user修复所有权。
报错里出现 Permission denied，先看路径再查属主
终端输出的错误行里一定带完整路径，比如 file_put_contents(/home/user/project/vendor/autoload.php) 或 Writing cache file ~/.composer/cache/repo/https---packagist.org/。这行就是线索——直接去查那个路径的归属：ls -ld /home/user/project/vendor/、ls -ld composer.lock、ls -ld $(composer config --global cache-dir)。只要任一输出第一列含 root root，问题就锁定在所有权错位，不是权限位（rwx）不够。
vendor/ 目录属主是 root？立刻归还控制权
90% 的 Permission denied 源头是 vendor/ 被 sudo composer install 污染过。别碰 chmod -R 777，它掩盖问题且触发安全告警。只做一件事：sudo chown -R $USER:$USER vendor/。注意末尾斜杠不能少，否则可能漏掉子目录。如果 composer.lock 也显示 root，一并加进去：sudo chown -R $USER:$USER vendor/ composer.lock。修复后立刻跑 composer install --no-scripts 测试结构能否生成；成功后再补 composer run-script post-install-cmd。
全局缓存或 ~/.composer 被 root 占了怎么办
composer config --global cache-dir 输出的路径若属主为 root，执行 sudo chown -R $USER:$USER $(composer config --global cache-dir)。整片 ~/.composer 都被污染？直接 sudo chown -R $USER:$USER ~/.composer。特别注意：插件缓存（如 ~/.composer/cache/plugins/）和 auth.json（~/.composer/auth.json）也得单独检查，它们常因镜像源 token 配置被 sudo 写入而卡住。
CI/CD 或 Docker 环境里权限更脆，得提前铺路
GitHub Actions、GitLab CI 默认用非 root 用户，但基础镜像（如旧版 php:alpine）可能让 /tmp 或 ~/.composer 缓存目录权限混乱。在流水线脚本开头加：mkdir -p .composer-cache && chmod 700 .composer-cache，再通过环境变量指定：COMPOSER_CACHE_DIR="$PWD/.composer-cache"。禁用插件和脚本能大幅降低权限需求：composer install --no-plugins --no-scripts --no-autoloader。Alpine 下若卡在 Extracting archive，加 -v 参数看是否是 musl libc 解包静默失败。
嵌套权限混乱最难排查：一次 sudo composer install 可能让 vendor/ 下混进个别 root 所有子目录，ls -la vendor/ 就能发现。这时候硬修不如删干净重来——前提是确认当前用户对项目根目录、composer.lock 和缓存路径都有完整所有权。
