vendor目录Permission denied的根本原因是属主被root锁定，而非权限数字过小；需先用ls -ld vendor/检查owner字段，若为root则说明此前用root执行过composer install，导致后续普通用户无法写入。
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 所有，说明整个初始化阶段就被污染了。
工作流任务拆解与模型编排技能。使用场景：(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 是谁。
