根本不是权限位(rwx)不够，而是vendor目录属主为root；应先用ls -ld vendor/确认归属，若第三列为root则删vendor和composer.lock后以当前用户重装，或执行sudo chown -r $user:$user vendor/ composer.lock。
vendor目录写权限不足，根本不是“权限不够”
报错里出现 Permission denied 写 vendor/，90% 不是 chmod 没开够，而是该目录属主是 root，而你正用普通用户运行 Composer 或 PHP。系统拦你，是因为“这目录不归你管”，不是“你不被允许读写”。ls -ld vendor/ 输出第三列若为 root，就坐实了这点。
三秒定位问题目录，别猜路径
终端报错一定带完整失败路径，直接盯那一行：
-
file_put_contents(/home/user/app/vendor/autoload.php): Failed to open stream: Permission denied→ 锁定vendor/ -
Could not write to /var/www/myapp/composer.lock→ 锁定composer.lock -
Writing cache file ~/.composer/cache/repo/...→ 锁定$(composer config --global cache-dir)
立刻查归属：
ls -ld vendor/ composer.lock $(composer config --global cache-dir)
任意一行第一列显示 root，就是所有权错位。
chown 是解药，chmod -R 777 是毒药
改归属才是正解，sudo chown -R $USER:$USER 只借权跑一次，不是让你去 sudo composer install——后者才是污染源头。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 修项目内：
sudo chown -R $USER:$USER vendor/ composer.lock - 修全局缓存：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 整个
~/.composer都被锁死？sudo chown -R $USER:$USER ~/.composer
别碰 chmod -R 777：它会让 vendor/bin/phpunit 这类可执行文件被 CI 拒收，Git 提交时提示 ownership changed，更糟的是某些子目录可能已混入 root 所有者，chown -R 都救不回来。
vendor 被 sudo 污染过，删比修更干净
如果之前误用过 sudo composer install，vendor/ 下很可能存在嵌套的 root 所有子目录。此时 chown -R 表面成功，但后续 composer update 可能只失败一半——部分文件写入成功、部分静默跳过，导致 autoload.php 不全或类找不到。
这种情况下，最稳妥的做法是：
- 确认当前用户：
whoami - 删掉整个
vendor/：rm -rf vendor/ - 再用普通用户重装：
composer install
尤其要注意：Web 服务器（如 PHP-FPM）和 CLI 用户不一致时，vendor/ 只需 CLI 可写，PHP 进程只需读取权限；若强行让 www-data 也写 vendor/，反而增加攻击面。
