根本原因是目录属主为root或当前用户无写权限，应先用ls -ld确认归属，再执行sudo chown -R $USER:$USER .修复所有权，禁用sudo composer install和chmod 777。
Composer install 时提示 Permission denied 创建 vendor 目录
根本原因是当前用户对目标目录（通常是项目根目录）没有写权限，Composer 尝试在其中创建 vendor/、composer.lock 等文件时被系统拒绝。常见于：用 sudo composer install 初始化过项目后切回普通用户；或项目目录归属为 root（如 Docker 容器外挂载、Vagrant 同步文件夹未正确设置 uid/gid）。
不要用 sudo composer install 修复——这会让 vendor/ 下所有文件属主变成 root，后续 php artisan 或本地开发服务器会因无权读取而报错。
- 先确认问题根源：
ls -ld .查看当前目录权限和属主；whoami确认当前用户 - 若目录属主是 root，运行
sudo chown -R $USER:$USER .（注意末尾的.，表示当前目录及内容） - 若属主正确但权限不足（如只有
dr-xr-xr-x），补上写权限：chmod u+w . - 再执行
composer install，应能正常创建vendor/
在 Docker 中运行 Composer 导致 mkdir(): Permission denied
Docker 容器内默认以 root 运行，但宿主机挂载的代码目录通常属于普通用户。容器里用 root 写入后，宿主机看到的文件属主是 UID 0（root），下次再进容器（尤其换了镜像或重启）可能因 UID 映射不一致导致权限混乱。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 构建阶段就该用非 root 用户：在
Dockerfile中添加useradd -u 1001 -m app和USER app - 运行时显式指定 UID/GID：启动容器时加
-u $(id -u):$(id -g)，让容器内进程以宿主机当前用户身份操作挂载目录 - 避免在容器里跑
composer install—— 改用多阶段构建，在 builder 阶段完成安装，只把vendor/复制到运行镜像中 - 若必须在容器内安装，确保挂载目录有写权限：
docker run -v $(pwd):/app:delegated -u $(id -u):$(id -g) php:8.2-cli composer install
Windows WSL2 下 Composer 报错 failed to open dir: Permission denied
WSL2 访问 Windows 文件系统（如 /mnt/c/Users/xxx/project）时，默认挂载为 metadata,uid=0,gid=0,umask=22,fmask=11，即所有文件属主都是 root，且 umask 拒绝组和其他用户的写权限。Composer 在此路径下无法创建子目录。
- 不要把项目放在
/mnt/c/...下——这是最直接的解法。改用 WSL2 原生文件系统路径，例如~/projects/myapp - 如果必须用 Windows 路径，需修改 WSL2 的挂载选项：编辑
/etc/wsl.conf，加入：[automount] options = "metadata,uid=1000,gid=1000,umask=022"
然后退出 WSL（
wsl --shutdown），重启终端 - 验证是否生效：
ls -ld /mnt/c应显示属主为你的用户，而非root
Git clone 后直接 composer install 失败，提示无法写入 composer.json
某些 Git 仓库的 composer.json 文件权限被设为只读（如 -r--r--r--），尤其在从 Windows 提交、或 CI 构建产物中拉取时。Composer 会尝试读取并重写该文件（例如更新 lock 或处理脚本），结果失败。
- 检查权限：
ls -l composer.json - 临时修复：
chmod u+w composer.json - 长期预防：提交前统一清理权限，Git 本身不跟踪文件权限位（除可执行位），所以
chmod 644 composer.json后再git add -f composer.json并提交 - CI 场景下可在脚本开头加一句：
find . -name 'composer.json' -exec chmod u+w {} \;
ls -l 看清是哪个路径、哪个文件、谁在拦你，比盲目搜“Composer 权限错误”快得多。很多问题本质不是 Composer 的 bug，而是文件系统权限模型和运行上下文没对齐。 
