答案是报错末尾完整路径指向vendor/、composer.lock或~/.composer/cache之一，需用ls -ld检查属主是否为当前用户，再执行sudo chown -R $USER:$USER修复归属，禁用chmod -R 777。
根本不是配置文件权限不够，而是它的归属被 root 占了——修复 composer.json 本身几乎从不解决问题，真正要查的是它所在的目录、vendor/、composer.lock 或缓存路径的属主。
报错里带完整路径，就照着它查归属
错误信息末尾那个路径才是关键线索，比如：file_put_contents(/home/alex/myapp/vendor/autoload.php): Permission denied → 锁定 vendor/；Writing cache file ~/.composer/cache/repo/... → 锁定全局缓存目录；Could not write to /var/www/myapp/composer.lock → 锁定 composer.lock。
立刻执行这三行，看输出第三列（属主）是不是你当前用户：
ls -ld vendor/ls -ld composer.lockls -ld $(composer config --global cache-dir)
只要任意一行显示 root root 或 www-data www-data，而你的用户名是 alex，问题就坐实了——不是权限位低，是东西不归你。
别碰 chmod -R 777，用 chown 归还控制权
chmod 控制“能不能读写”，chown 才决定“这东西归不归你”。误用 chmod -R 777 会导致：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
vendor/bin/phpunit这类可执行文件被 CI 工具或安全扫描器直接拒收 - Git 提交时提示
ownership changed - 后续
composer update可能只失败一半，连chown -R都救不回来
正确做法是精准归还所有权：
- 仅
vendor/归属异常：sudo chown -R $USER:$USER vendor/ -
composer.lock也被 root 占了：sudo chown $USER:$USER composer.lock - 全局缓存目录污染：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 整个
~/.composer都是 root 的：sudo chown -R $USER:$USER ~/.composer，再补一句chmod -R u+rw ~/.composer防 umask 导致子目录不可写
Windows 和 WSL 下的特殊坑
在 Windows 上看到 Access is denied，大概率不是权限问题，而是防病毒软件拦截了 .bat 文件生成，或 PowerShell 对当前用户 PATH 解析异常。在 WSL 中访问 /mnt/c/ 下项目时，chown 和 chmod 会失效——NTFS 不支持 Linux uid/gid。
稳解法：
- Windows：临时禁用 Windows Defender 实时防护，或改用 Git Bash 运行
composer install - WSL：把项目移到 WSL 原生路径（如
~/projects/myapp），再运行命令 - Docker：启动容器时指定 UID/GID，避免宿主机与容器用户 UID 不一致导致
vendor/在宿主机上变成 root 所有
最麻烦的不是第一次报错，而是 sudo composer install 留下的所有权残留——它不会立刻显现，但会在后续 composer dump-autoload、CI 构建或 IDE 同步时突然爆发。每次看到 Permission denied，第一反应不该是加 sudo，而是 ls -ld 看归属。
