根本原因是旧文件属主为root导致普通用户无权删除，而非磁盘满或杀毒软件拦截；需用sudo chown -r $user:$user修复vendor/、composer.lock及缓存目录所有权。
根本不是文件被“锁定”，而是旧文件属主为 root，当前用户没资格删它。Composer 试图覆盖 vendor/autoload.php 或 composer.lock 时失败，90% 情况下不是磁盘满或杀毒软件拦截，而是上一次用 sudo composer install 留下的 root 所有文件，普通用户连 unlink() 都被系统拒绝。
报错里出现 unlink、rename 或 file_put_contents 失败，先查路径归属
错误行通常带具体路径，比如：unlink(/home/user/app/vendor/autoload.php): Permission denied 或 rename(/tmp/xxx,/home/user/app/composer.lock): Permission denied。这行就是线索——立刻查它：
-
ls -ld /home/user/app/vendor/—— 看第一列和第三列是否含root -
ls -ld /home/user/app/composer.lock—— 单独文件也常被污染 -
ls -ld $(composer config --global cache-dir)—— 缓存里残留的 root 文件会卡住后续 install
只要任一输出显示 root root，就确认是所有权错配，不是权限位（rwx）不够。
别删 vendor 重装，先归还控制权再覆盖
直接 rm -rf vendor/ 能绕过问题，但治标不治本；下次误用 sudo 还会复发。正确做法是让 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) - 末尾必须带斜杠（
vendor/），否则chown -R可能漏掉子目录内容
执行后立刻试 composer install --no-scripts，验证能否生成基础结构；成功后再补 composer run-script post-install-cmd。
Docker 或 CI 环境下，UID 不匹配会导致覆盖静默失败
宿主机 UID 是 1001，容器却以 UID 0（root）运行，挂载进来的 vendor/ 在容器内属 root，但 Composer 尝试覆盖时用的是非 root 用户上下文，rename() 直接返回 EPERM（而非 EACCES），错误信息可能不显眼。
- 本地开发：启动容器时指定
--user $(id -u):$(id -g)或在docker-compose.yml里写user: "${UID:-1001}:${GID:-1001}" - CI 流水线（如 GitHub Actions）：无需处理 UID，但要禁用插件减少权限依赖：
composer install --no-plugins --no-scripts - Alpine 镜像注意：
musl libc对renameat2()的支持较弱，加-v参数看是否卡在解包阶段
最易被忽略的是嵌套权限混乱：一次 sudo composer install 可能让 vendor/ 下个别子目录（如 vendor/bin/）仍属 root，而其他部分属你。用 ls -la vendor/ | grep root 能揪出这些漏网之鱼——它们不会在 ls -ld vendor/ 里暴露，却足以让后续 composer update 半途崩溃。
