报错中带路径的那一行指向vendor/、composer.lock或~/.composer/cache，问题根源是目录属主为root而非当前用户，需用ls -ld确认后执行sudo chown -r $user:$user修复。
直接看报错里带路径的那一行，它指哪，问题就在哪——不是“Permission denied”四个字本身，而是后面跟着的/path/to/vendor/autoload.php、composer.lock或~/.composer/cache/这类具体位置。
报错里出现file_put_contents或mkdir失败，先查属主
这类错误几乎全是所有权错配，不是权限数字不够。Linux/macOS 的写入控制优先看“归不归你”，再看“允不允许写”。
- 复制报错中的完整路径（比如
/home/alex/myapp/vendor/autoload.php），取其父目录：ls -ld /home/alex/myapp/vendor/ - 同样检查
ls -ld composer.lock和ls -ld $(composer config --global cache-dir) - 只要任一输出第三列（属主）不是
$(whoami)（比如显示root root），就确认是归属问题 - 别用
chmod -R 777——它会让vendor/bin/phpunit被 CI 拒收，Git 提交时提示 ownership changed，后续composer update可能只失败一半
修复命令必须用chown -R $USER:$USER，不是sudo composer install
sudo composer install是污染源头，不是解法。它让vendor/下所有文件变成root所有，后续任何普通用户操作都会卡住。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 修复项目内目录：
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 -
sudo在这里只是临时提权跑chown，不是让你用它跑 Composer 命令本身
Docker、CI 或 Windows 下的隐性权限坑
这些环境不报在明面上，但一样拦着构建流程。
- Docker：宿主机 UID 是 1001，容器默认用 UID 0（root）→ 挂载卷时加
user:1001，或 Dockerfile 里加USER 1001 - CI 流程中
composer global require失败？先跑composer config --global home，如果输出是/root/.composer或/var/www/.composer，说明环境被污染 - Windows：报
Access is denied但没路径？大概率是杀软拦截了.bat生成，或 IDE 正在监听vendor/导致文件句柄锁定；改用 Git Bash 或加--no-scripts跳过脚本环节
真正难搞的不是第一次修复，而是嵌套污染：比如vendor/里部分子目录属root、部分属你，chown -R有时都救不回来，只能删掉vendor/重来——所以别让sudo composer install发生第二次。
