答案是vendor/目录属主为root导致写入失败，需用sudo chown -R $USER:$USER vendor/修复所有权，禁用chmod 777；若composer.lock或~/.composer/cache也属root，一并修复。
vendor/ 目录属主是 root？立刻归还控制权
90% 的 Permission denied 报错，根源就是 vendor/ 被 sudo composer install 污染过。终端报错里只要出现类似 file_put_contents(/path/to/vendor/autoload.php)，就说明问题锁定在 vendor/ ——它现在归 root，不归你。
别碰 chmod -R 777 vendor/，它会让 vendor/bin/ 下的可执行文件被 CI 工具拒绝、Git 提示 ownership changed、后续 composer update 卡在半途。
- 先确认归属：
ls -ld vendor/，如果第一列显示root root，坐实问题 - 安全修复：
sudo chown -R $USER:$USER vendor/（注意末尾斜杠不能少） - 若
composer.lock也显示root，一并加入：sudo chown -R $USER:$USER vendor/ composer.lock - 修复后验证：
composer install --no-scripts看能否生成基础结构
全局缓存目录 ~/.composer/cache 归属错误怎么修
报错里出现 Writing cache file ~/.composer/cache/repo/https---packagist.org/，说明 ~/.composer/cache 被 root 占了。这不是权限位（rwx）不够，而是“这目录不认你这个主人”。
运行 composer config --global cache-dir 获取真实路径，再用 ls -ld 查归属。只要输出里 owner 不是你当前用户名（$(whoami)），就得修。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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 $(composer config --global cache-dir) - 整片
~/.composer都是root？直接重置：sudo chown -R $USER:$USER ~/.composer - 特别检查插件缓存：
ls -ld ~/.composer/cache/plugins/和认证文件：ls -ld ~/.composer/auth.json，它们常因镜像 token 配置被sudo写入而卡住
CI/CD 或 Docker 里权限更脆，得提前铺路
GitHub Actions、GitLab CI 默认用非 root 用户，但基础镜像（如旧版 php:alpine）可能让 /tmp 或 ~/.composer/cache 权限混乱。Docker 中 bind mount 宿主机目录后跑 composer install 更是高危操作。
- 流水线开头加：
mkdir -p .composer-cache && chmod 700 .composer-cache - 指定本地缓存：
COMPOSER_CACHE_DIR="$PWD/.composer-cache" composer install - 降低权限需求：
composer install --no-plugins --no-scripts --no-autoloader - Docker 构建时，不要
USER root执行composer install；改用非 root 用户（如USER 1001），并在Dockerfile开头创建该用户
嵌套权限混乱最难排查，ls -la vendor/ 是照妖镜
一次 sudo composer install 可能让 vendor/ 下混进个别 root 所有子目录，表面 ls -ld vendor/ 显示你自己的名字，但里面藏着雷。这种嵌套错配，chown -R 有时都救不回来。
真正可靠的排查方式是深入一层：ls -la vendor/ | head -20，扫一眼有没有某行 owner 是 root。一旦发现，说明污染已渗透——最稳解法是删掉整个 vendor/ 和 composer.lock，再用当前用户重装。
最容易被忽略的是：报错路径未必是你要修的目录。比如 opcache 缓存写失败、PHP 自身临时目录（sys_temp_dir）不可写，都会引发连锁反应，最终表现为 vendor/autoload.php 写入失败。所以，永远先盯死报错里那个完整路径，再查归属，再动手。
