根本原因是当前用户对 vendor/、composer.lock 或缓存目录无写权限，常见于目录归属为 root 或 docker 挂载权限不匹配；应先用 ls -l 定位具体路径，再针对性修复归属或重建 vendor。
为什么 composer install 会 Permission denied？
根本原因不是 Composer 本身没权限，而是它在写入目录（比如 vendor/、composer.lock 或缓存路径）时被系统拒绝。最常见的是：当前用户对目标目录没有写权限，或者目录归属是 root（比如之前用 sudo composer install 运行过），导致普通用户后续无法修改。
检查并修复 vendor 目录权限的实操步骤
先确认问题是否出在 vendor/：
运行 ls -ld vendor，如果看到类似 drwxr-xr-x 2 root root，说明归属是 root —— 这就是罪魁祸首。
- 别用
sudo chown -R $USER:$USER vendor粗暴递归改所有子目录，容易破坏某些包自带的只读文件（如 Phar 包内嵌资源） - 正确做法是删掉整个
vendor/和composer.lock，再用当前用户重新运行composer install - 如果项目不允许删
composer.lock（如生产环境部署），至少确保vendor/目录本身归属是你自己：chown $USER:$USER vendor，然后chmod u+w vendor
Composer 缓存目录权限冲突怎么办
Composer 默认缓存路径是 ~/.composer/cache，有时这个目录被创建成 root 所有，后续所有 composer 命令都会卡在「写缓存失败」。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 查缓存位置：
composer config --global cache-dir - 看归属：
ls -ld $(composer config --global cache-dir) - 修复方式（二选一）：
– 改归属：sudo chown -R $USER:$USER ~/.composer/cache
– 或换路径（更干净）：composer config --global cache-dir /home/$USER/.cache/composer，再手动创建并赋权：mkdir -p /home/$USER/.cache/composer && chown $USER:$USER /home/$USER/.cache/composer
CI/CD 或 Docker 环境里 Permission denied 的特殊处理
这类环境常以非 root 用户运行，但挂载的宿主机目录默认属 root，容器内用户无权写入 vendor/。
- Docker 中避免用
root用户执行composer install，改用与宿主机 UID 一致的用户：docker run -u $(id -u):$(id -g) ... - GitHub Actions 等 CI 工具中，不要在
cache: composer后直接跑composer install，因为缓存解压后可能继承错误权限；加一步chown -R $USER:$USER vendor（或直接删 vendor 再装） - 如果用
composer create-project初始化项目，注意它默认会把vendor/设为只读（尤其带--no-interaction时），可追加--remove-vcs并手动chmod u+w vendor
真正麻烦的从来不是报错本身，而是权限问题常跨层存在——可能表现在 vendor，根子却在缓存或 Docker 卷挂载方式上。每次遇到，先用 ls -l 看清具体哪个路径被拒，比盲目 chmod 777 管用得多。
