直接结论：90%的“Permission denied”是目录属主非当前用户所致，需用ls -ld确认归属后执行sudo chown -R $USER:$USER .修复项目目录所有权，禁用sudo composer install和chmod 777。
直接用 sudo composer install 会失败，不是权限不够，而是 Composer 主动拒绝——它怕你把 vendor/ 写进系统目录，污染全局环境。真正要配的不是“root 权限”，而是当前用户对项目目录的完整控制权。
为什么 composer install 报 “Permission denied” 却不提示具体路径
常见现象是卡在 Writing lock file 或报错 file_put_contents(./composer.lock): Failed to open stream: Permission denied，但没说哪个文件或目录不可写。根本原因通常是：
• 当前目录（含 composer.json、composer.lock）属主不是当前用户
• vendor/ 已存在，但由 root 或其他用户创建，当前用户无写权限
• 项目在 OneDrive、iCloud、WPS 同步盘等“虚拟文件系统”里，Linux/macOS 下 flock() 失败，Windows 下 ACL 权限异常
Linux/macOS 下修复目录权限的三步操作
别碰 sudo，先确认当前用户身份和目录归属：
- 运行
whoami和ls -ld .，看输出里 owner 是否一致 - 如果 owner 不是当前用户，执行
sudo chown -R $(whoami):$(whoami) .（注意结尾的.，只改当前目录及子项） - 再清掉残留的
vendor/和composer.lock：rm -rf vendor composer.lock，然后重试composer install
Windows 下 vendor/ 权限被同步工具锁死怎么办
OneDrive、腾讯微云、阿里云盘等会在后台扫描文件，导致 composer install 在解压时拿不到写锁，报错类似 rename(): Cannot rename …: Permission denied。这不是 PHP 权限问题，是文件系统级冲突：
- 临时退出同步客户端，或右键项目文件夹 → “取消与 OneDrive 的链接”
- 把项目移到非同步路径下，比如
C:\dev\myproject，而非C:\Users\Alice\OneDrive\code\myproject - 若必须放同步盘，加个
.gitignore并确保vendor/、composer.lock已被忽略，避免同步工具反复扫描
CI/CD 环境里 composer install 频繁失败的隐藏原因
Docker 容器、GitHub Actions、GitLab CI 默认用 root 用户跑命令，但 Composer 会拒绝；而有些镜像又把 /app 目录设为 root:root 且不可写：
- 在
Dockerfile中加一行：RUN mkdir -p /app && chown www-data:www-data /app，再USER www-data - GitHub Actions 中，在
steps前加：run: sudo chown -R ${{ github.actor }}: /github/workspace - 永远不要在 CI 脚本里写
sudo composer install——它不会成功，只会报Do not run Composer as root
最常被忽略的一点：权限问题从来不是孤立的。它往往和路径是否在同步盘、用户是否切换过、容器是否以非 root 启动混在一起。先跑 ls -l 或 dir 看一眼 owner 和 permissions，比反复查文档快得多。
