vendor目录报Permission denied，90%是被root占用——应执行sudo chown -R $USER:$USER vendor/修复归属，而非chmod；若ls -ld vendor显示root root，则确认属主错误；WSL或Docker中需避免/mnt/挂载点，改用原生路径或预设容器用户归属。
vendor目录报Permission denied，90%是它被root占了——别改chmod，直接chown归还所有权。
看报错路径定位问题源头
终端输出里带完整路径的错误才是关键线索：
-
file_put_contents(/path/to/project/vendor/autoload.php): Failed to open stream: Permission denied→ 问题在vendor/目录本身 -
Could not write to /path/to/project/composer.lock→ 问题在composer.lock文件或其所在目录 -
Writing cache file ~/.composer/cache/repo/https---packagist.org/...→ 问题在~/.composer/cache/
只要报错路径出现/root/.composer、/var/www/.composer或/mnt/c/开头，基本可以确定是环境配置错位，不是项目本身的问题。
用ls -ld确认归属是否为当前用户
执行这三条命令，重点看每行输出第一列（权限位）和第三列（属主）：
ls -ld vendor/ ls -ld composer.lock ls -ld $(composer config --global cache-dir)
如果任意一行显示root root或www-data www-data，而你的用户名是alex，那问题就在这儿。注意：drwxr-xr-x 12 root root里的root是属主，不是权限不足——chmod解决不了归属问题。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
chown修复比chmod -R 777安全且治本
以下操作全部基于当前用户身份（$USER）：
- 修项目内目录：
sudo chown -R $USER:$USER vendor/ composer.lock - 修全局缓存：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 如果整个
~/.composer都属root：sudo chown -R $USER:$USER ~/.composer
别碰chmod -R 777：它会让vendor/bin/phpunit这类可执行文件被CI工具拒绝，Git提交时还会提示ownership changed；更糟的是，有些子目录可能已混进root所有者，chown -R都救不回来，只能删掉vendor/重装。
WSL或Docker环境下要特别注意挂载点
在WSL中访问/mnt/c/Users/xxx/project时，mkdir()失败大概率不是权限位问题，而是NTFS不支持Linux uid/gid。最稳解法是把项目移到WSL原生路径，比如~/projects/myapp再运行composer install。
Docker里常见挂载宿主机目录后容器用户（如www-data）无权写vendor/。此时不要在容器里加sudo，应在构建阶段用chown -R www-data:www-data /app预设归属，或改用非root用户挂载。
复杂点在于：一旦vendor/里混入不同属主的子目录，后续composer update可能只失败一半，表面看起来“有时行有时不行”。这种时候别硬扛，rm -rf vendor/再重来反而最快。
