报错 mkdir(): Permission denied 的关键在错误末尾路径，常见于 vendor/、~/.composer/cache/ 或 WSL 的 /mnt/c/ 路径；需用 ls -ld 确认归属权限，vendor/ 多因误用 sudo 导致属主为 root，应删 vendor/ 和 composer.lock 后以当前用户重装。
这是典型的文件系统写入权限缺失，不是 Composer 坏了，而是它被操作系统拦在了 mkdir() 这一步。
报错 mkdir(): Permission denied 到底在哪个路径失败？
错误信息末尾的 mkdir(): Permission denied in ... 后面跟着的路径才是关键。常见三类位置：
-
vendor/（项目根目录下）—— 最常见，说明当前用户对该项目目录无写权限 -
~/.composer/cache/（全局缓存）—— 多因曾用sudo composer导致该目录属主为 root -
/mnt/c/...（WSL 下挂载的 Windows 路径）—— 文件系统不支持 Linux 权限模型，chmod无效
先运行 ls -ld vendor/ 或 ls -ld $(composer config --global cache-dir) 确认归属和权限，别猜。
vendor/ 目录报 Permission denied 怎么修？
90% 是因为之前误用了 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/—— 若里面有 Phar 包或符号链接，可能破坏结构 - 安全做法：删掉整个
vendor/和composer.lock，再用当前用户重装：rm -rf vendor composer.lock && composer install - 如果
composer.lock不可删（如 CI 部署），至少确保vendor/目录本身可写：chown $USER:$USER vendor && chmod u+w vendor
~/.composer/cache 权限混乱怎么处理？
这个目录一旦被 root 占用，所有 composer install、composer update、composer global require 都会卡在「写缓存」阶段，错误不明显但必失败。
- 检查命令：
ls -ld ~/.composer/cache，若 owner 不是当前用户，就是它 - 推荐改路径而非硬修归属：
composer config --global cache-dir ~/.cache/composer，再执行mkdir -p ~/.cache/composer && chown $USER:$USER ~/.cache/composer - 改完后务必运行
composer clear-cache验证是否生效
Docker / WSL 环境下为什么总修不好？
根本原因是 UID/GID 映射断裂，不是权限数字不对，而是“谁”在操作文件不匹配。
- WSL 中避免在
/mnt/c/下跑composer install；移到~/projects/等原生路径 - Docker 构建时，不要用
USER root执行composer install；应在Dockerfile中创建与宿主机 UID 一致的用户，并chown -R 1001:1001 /app再切换 - GitHub Actions 等 CI 工具中，
cache: composer解压后的文件常继承错误属主，加一步chown -R $USER:$USER vendor或直接删 vendor 重装
最易被忽略的是：错误里显示的路径，往往只是失败的“最后一站”，真正的问题可能藏在上游缓存目录或父目录的 umask 设置里。定位必须从 ls -ld 开始，不能只看报错行。
