95%的项目根目录权限不足是属主错配所致，需用ls -ld检查项目路径、vendor/及composer.lock归属，再执行sudo chown -R $USER:$USER精准修复，禁用chmod u+w等无效操作。
项目根目录权限不足，95% 是属主错配，不是 chmod 能解决的。 报错里出现 file_put_contents(/path/to/project/composer.lock) 或往 vendor/ 写文件失败，说明 Composer 想改你当前目录下的东西，但系统说“你不是这个目录的主人”。
怎么快速确认是不是根目录归属问题
终端报错路径里带项目路径（比如 /home/alex/myapp/），就立刻查它：
- 运行
ls -ld /path/to/project，看第三列是不是你的用户名；如果是root root或别的用户，就是归属错了 - 再顺手查
ls -ld /path/to/project/vendor/和ls -ld /path/to/project/composer.lock，只要任一属主不是你，就坐实了问题 - 别信
ls -l只看权限数字——drwxr-xr-x看起来没问题，但 owner 是 root，普通用户照样被拒
修复命令必须带 -R 且只针对目标目录
不能只改目录本身，子目录和文件也得一起收回来，否则 Composer 后续生成的 autoload.php、installed.json 还是写不进：
- 如果整个项目目录都归 root：
sudo chown -R $USER:$USER /path/to/project - 如果只是
vendor/和composer.lock被污染：sudo chown -R $USER:$USER /path/to/project/vendor/ /path/to/project/composer.lock - 执行完立刻验证：
ls -ld /path/to/project应该显示你的用户名在第三列
为什么 chmod u+w . 常常无效
单纯加写权限，挡不住两个底层机制：
- 父目录没写权，子目录
chmod也没用——先touch ./test && rm ./test确认根目录本身可写 - 新文件权限受
umask控制：如果umask是0022，Composer 生成的文件默认是644（无组/其他写权），某些 autoload 逻辑会失败；开发机建议设为umask 0002 - Windows 下尤其注意：OneDrive、腾讯微云等同步工具会锁住
composer.json所在目录，临时退出同步再试
真正要命的是“修了一半”——只改了 vendor/ 归属却留着旧的 composer.lock，或者修复了项目目录却忘了 ~/.composer/cache/ 也被 sudo 污染过。所有路径必须统一归属，且最好在修复后删掉 vendor/ 和 composer.lock 重装，避免残留状态干扰。
