Composer报错“Permission denied”时应先用ls -ld检查vendor/、composer.lock和~/.composer/cache/权限，优先chown修复属主，慎用chmod，避免sudo导致嵌套权限混乱。
Composer 报错 “Permission denied” 时先确认是哪个目录没权限
绝大多数情况下，composer install 或 composer update 失败并提示 file_put_contents(...): Permission denied，问题出在 vendor/、composer.lock 或缓存目录（如 ~/.composer/cache/）——不是整个项目根目录，更不是系统级路径。别一上来就 sudo chmod -R 777 .，这会让后续部署和 CI/CD 出问题。
用 ls -ld 查当前用户对关键目录的真实权限
执行以下命令快速定位：
ls -ld vendor/ ls -ld composer.lock ls -ld ~/.composer/cache/
重点关注三列：属主（user）、属组（group）、权限位（rwx）。常见异常包括：
-
vendor/属主是root，但当前用户是www-data或普通开发用户 -
~/.composer/cache/权限是drwx------（即 700），但被错误创建为 root 所有 -
composer.lock是只读文件（-r--r--r--），且属主不是当前用户
正确修复：优先用 chown，谨慎用 chmod
权限问题本质是“谁拥有它”，不是“它允许谁访问”。所以先改归属，再按需调权限：
- 修复项目内目录：
chown -R $USER:$USER vendor/ composer.lock - 修复全局缓存：
chown -R $USER:$USER ~/.composer/cache/ - 如果因 Docker 或 CI 环境导致属主混乱（如 UID 不匹配），可在容器启动时加
-u $(id -u):$(id -g) - 仅当明确需要组写入（如团队共享 dev 环境）才设
chmod g+w vendor/；生产环境应保持755或750，绝不用777
预防下次再出问题：检查 Composer 运行身份与初始化方式
很多权限问题其实源于“用错了用户装了第一次”：
- 从不用
sudo composer create-project初始化项目 - CI 脚本中避免用
root用户运行composer install - 在 Docker 中，确保
WORKDIR和composer install步骤使用同一非 root 用户（如USER 1001） - 若反复遇到
~/.composer权限错，可临时重置：rm -rf ~/.composer && composer --version（自动重建，且属主为当前用户）
最麻烦的不是修一次权限，而是某次 sudo composer 后，vendor/ 下混进了 root 所有子目录——这种嵌套权限不一致，chown -R 也救不回来，只能删掉 vendor/ 重装。
