Composer写入失败90%是目录归属或权限错配，需先用ls -ld定位具体路径（如vendor/、composer.lock、~/.composer/cache等），再针对性修复归属或迁移缓存目录至~/composer-cache，严禁滥用sudo。
直接结论：Composer写入失败，90%是目录归属或权限错配，不是网络或PHP配置问题。必须先定位具体哪个路径被拒绝写入，再针对性修复。
查清到底是哪个目录写不进去
Composer报failed to write时，错误信息末尾通常会带路径（如~/.composer/cache/files/...或./vendor/...）。但有时只报Permission denied没给路径——这时得主动挖：
- 运行
composer config --global cache-dir确认缓存路径，再ls -ld $(composer config --global cache-dir)看owner和权限 - 运行
composer config --global home查全局配置目录（常为~/.composer），同样用ls -ld检查 - 进项目根目录，
ls -ld vendor/和ls -ld .（当前目录权限影响composer.lock写入） - 如果在Docker或WSL里，特别留意路径是否落在
/mnt/c/或/var/www这类挂载区——Linux权限模型在那里基本失效
chown -R $USER:$USER 不是万能解药
很多人看到owner是root就无脑执行sudo chown -R $USER:$USER ~/.composer，结果仍失败。原因有三：
- 只改了
~/.composer，但缓存目录（~/.cache/composer）或COMPOSER_HOME指向的其他路径仍是root属主 - 用了
sudo composer install一次，就把整个vendor/写成root-owned，后续普通用户连rm -rf vendor都可能被拒 - WSL下
/mnt/c目录的文件系统不保存uid/gid，chown执行成功但实际无效
正确做法：先whoami确认当前用户，再对所有可疑路径逐个ls -ld，只对真正属于root的路径执行sudo chown -R $USER:$USER，且务必包含$(composer config --global cache-dir)和$(composer config --global home)两个路径。
缓存目录换到家目录下最省心
全局缓存默认在~/.cache/composer或~/.composer/cache，但这些路径容易被系统清理或权限策略干扰。更稳妥的是迁移到完全由你控制的位置：
- 新建目录：
mkdir -p ~/composer-cache - 赋权：
chown $USER:$USER ~/composer-cache && chmod 755 ~/composer-cache - 切换路径：
composer config --global cache-dir ~/composer-cache - 清旧缓存：
composer clear-cache（此时会清掉原路径，新路径自动生效）
这招对WSL、Docker、共享主机尤其有效——只要~/可写，缓存就稳。
别让sudo污染你的环境
执行sudo composer install看似能跳过报错，实则埋雷：
- 生成的
vendor/和composer.lock归root所有，下次普通用户运行composer update会卡在“无法覆盖” -
composer global require若用sudo，二进制文件会落到/root/.composer/vendor/bin/，你根本执行不到 - 某些CI/CD流程（如GitHub Actions）以非root用户运行，本地用sudo装的包在线上直接不可见
一旦误用sudo，立刻执行sudo chown -R $USER:$USER ~/.composer和sudo chown -R $USER:$USER ./vendor回滚，然后rm -f composer.lock && composer install重来。
最麻烦的其实是WSL挂载Windows盘或Docker bind mount场景——chmod/chown全失效，唯一可靠解法是把项目移到~/或/tmp等纯Linux文件系统路径下操作。这点容易被忽略，但真出问题时，90%的人会花两小时调权限，却没想到该换路径。
