答案是vendor/目录属主为root导致写入失败，应执行sudo chown -R $USER:$USER vendor/修复所有权，再运行composer install --no-scripts验证。
vendor/ 目录被 root 占了，composer install 就会卡在覆盖写入
报 Permission denied 不是 vendor 里文件“只读”，而是当前用户根本不是目录所有者。常见于误用 sudo composer install 后，vendor/ 下混进大量 root:root 子目录。此时哪怕你 chmod -R 777 vendor/，也解决不了——Linux 不允许非属主用户修改属主为 root 的目录内容。
快速确认：运行 ls -ld vendor/，如果输出第一列含 root，问题就在这儿。别修权限位，直接归还所有权：
-
sudo chown -R $USER:$USER vendor/（末尾斜杠不能少） - 顺手检查
composer.lock：ls -ld composer.lock，若也是root，一并加入：sudo chown -R $USER:$USER vendor/ composer.lock - 修复后先跑
composer install --no-scripts，验证能否生成基础结构；成功后再补composer run-script post-install-cmd
缓存包解压失败，composer install --force-reinstall 仍报错
--force-reinstall 会删掉包目录再重下，但若缓存目录（如 ~/.composer/cache/）本身归属 root，它连 zip 文件都打不开。错误常表现为 file_put_contents(/home/user/project/vendor/autoload.php): failed to open stream: Permission denied 或静默卡在 Extracting archive。
查缓存路径：composer config --global cache-dir，然后 ls -ld 看归属。只要输出带 root，就执行：
sudo chown -R $USER:$USER $(composer config --global cache-dir)- 若整片
~/.composer都被污染：sudo chown -R $USER:$USER ~/.composer - 特别注意插件缓存路径（如
~/.composer/cache/plugins/）和~/.composer/auth.json，它们也常因sudo composer global require被写成 root 所有
Docker / CI 环境里，composer install 覆盖失败更隐蔽
GitHub Actions、GitLab CI 默认用非 root 用户，但基础镜像（如旧版 php:alpine）可能让 /tmp 或 ~/.composer/cache 权限混乱，导致覆盖时无法写入临时解压目录。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
预防性操作比事后修复更可靠：
- 流水线开头加：
mkdir -p .composer-cache && chmod 700 .composer-cache - 通过环境变量指定缓存位置：
COMPOSER_CACHE_DIR="$PWD/.composer-cache" - 降低权限依赖：
composer install --no-plugins --no-scripts --no-autoloader - Alpine 下若卡在
Extracting archive，加-v看是否是 musl libc 解包失败——这种不是权限问题，得换镜像或加apk add zip
嵌套所有权混乱：删了 vendor 也救不回来
一次 sudo composer install 可能只污染部分子目录，比如 vendor/laravel/framework 是 root，而 vendor/monolog/monolog 是正常用户。这种混合状态，ls -la vendor/ 一眼就能发现——混着 root 和 $USER 的行。
此时 chown -R 多半有效，但若已出现“部分包覆盖失败、部分成功”的诡异现象，说明 vendor 内部状态已不一致。最稳妥的做法是：
- 删掉整个
vendor/目录 - 确保
composer.lock和缓存目录所有权都已修正 - 再跑
composer install，而不是--force-reinstall——后者仍依赖现有 vendor 结构，容易复现旧问题
真正麻烦的不是权限本身，而是所有权错位后产生的混合状态：它不会立刻报错，却会让后续的 update、require 行为变得不可预测。
