详解 Composer 安装时 vendor 目录权限锁定与安全加固-composer-PHP中文网

vendor目录permission denied的根本原因是属主被root锁定，而非权限数字过小；需先用ls -ld vendor/检查owner字段，若为root则说明此前用root执行过composer install，导致后续普通用户无法写入。

详解 composer 安装时 vendor 目录权限锁定与安全加固

vendor 目录报 Permission denied，95% 不是权限数字太小，而是属主被 root 锁死了——别急着 chmod -R 777，先看 ls -ld vendor/ 输出的 owner 字段。

为什么 `composer install` 后 vendor 目录写不了

根本原因不是 umask 或 chmod 设置不对，而是你或 CI/CD 环境用 root 执行过 composer install，导致整个 vendor/ 下文件和目录属主变成 root:root。普通用户后续运行 composer update 或写入 autoload.php 时，系统直接拒绝，错误如：file_put_contents(/path/to/vendor/autoload.php): Permission denied。

常见触发场景：Dockerfile 里没指定 USER、GitHub Actions 缓存解压后继承 root UID、sudo composer install 一次就全污染
chmod -R 777 vendor/ 不仅无效（属主还是 root），还会让 vendor/bin/phpunit 这类可执行脚本被 CI 安全扫描拦截
Windows WSL 用户注意：/mnt/ 下挂载的 NTFS 盘默认不支持 chmod，需在 /etc/wsl.conf 中启用 metadata=true 并重启

怎么快速确认 vendor 是否被 root 污染

终端报错路径含 vendor/ 就直接锁定目标。执行两行命令：

ls -ld vendor/
ls -l vendor/ | head -n 3

若第一行输出类似 drwxr-xr-x 12 root root，或子目录里混着 root 属主，问题就在这儿。顺便检查 composer.lock：ls -l composer.lock，它若也是 root 所有，说明整个初始化阶段就被污染了。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

别只看 vendor 本身——vendor/composer/、vendor/autoload.php、vendor/bin/ 都要扫一眼归属
如果项目根目录（.）也显示 root root，说明 git clone 或复制时用了 sudo，得一并修复

修复 vendor 权限的正确顺序

优先修属主，再考虑是否需要 chmod。暴力 chown -R 有风险，删重装更干净。

稳妥做法：先 rm -rf vendor composer.lock，确保当前用户对项目目录有写权限（touch test && rm test 测试），再以普通用户跑 composer install
不能删 composer.lock 的场景（如生产部署）：至少执行 sudo chown $USER:$USER vendor/ + chmod u+w vendor/，让当前用户能写入
CI 脚本中加兜底：比如 GitHub Actions 里，在 composer install 后补一行 chown -R $GITHUB_ACTOR:$GITHUB_ACTOR vendor/
Docker 构建时，用 RUN umask 0022 && composer install --no-dev --optimize-autoloader，从源头避免宽松权限

`~/.composer` 和缓存目录的权限常被忽略

全局配置和缓存出问题，会导致 composer global require 失败、composer config --global home 返回空、甚至 composer update 卡在 “Writing cache file”。根源同样是 ~/.composer 被 root 占用。

查归属：ls -ld ~/.composer，如果不是 $USER:$USER，立刻修复：sudo chown -R $USER:$USER ~/.composer
加固安全：chmod 700 ~/.composer（禁止组和其他用户访问），chmod 600 ~/.composer/auth.json（哪怕文件不存在，也要确保创建时权限正确）
缓存路径可手动重定向：composer config --global cache-dir "$HOME/.composer-cache"，再 mkdir -p $HOME/.composer-cache 并确认属主

真正麻烦的从来不是 chmod 数字，而是属主错位后残留的隐性依赖——比如某个包的 post-install-cmd 创建了符号链接，chown -R 会把软链目标也拖进去改，引发意外。修之前，先看清 owner 是谁。