应执行composer global show -v查看Cache directory行确认真实路径，而非仅信config --global cache-dir输出；最稳方式是设优先级最高的环境变量COMPOSER_CACHE_DIR，并确保路径存在、可写且不挂载于NFS等受限存储。
全局缓存策略配不对，Composer 就不会真正复用包——不是慢，是白干。
怎么确认当前生效的 cache-dir 路径
别信 composer config --global cache-dir 的输出，它只显示配置值，不反映运行时真实路径。真正起作用的是 Composer 启动后解析出的路径：
- 执行
composer global show -v，找Cache directory:那一行，这才是实际读写位置 - 或者跑一次
composer install（哪怕项目已装好），立刻检查目标目录下是否新增了archived/或repo/子目录 - 如果用了
COMPOSER_CACHE_DIR却没生效，大概率是之前用composer config --global cache-dir写死了旧值，得先运行composer config --global --unset cache-dir
设 COMPOSER_CACHE_DIR 是最稳的方式
这个环境变量优先级最高，能强制覆盖所有其他配置，特别适合 CI/CD 和多用户机器：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Linux/macOS：在
~/.zshrc里加export COMPOSER_CACHE_DIR="/mnt/ssd/composer-cache"，然后source ~/.zshrc - Windows PowerShell：
$env:COMPOSER_CACHE_DIR="D:\composer-cache"；CMD 则用set COMPOSER_CACHE_DIR=D:\composer-cache - Docker 中必须显式注入：
ENV COMPOSER_CACHE_DIR=/cache（Dockerfile）或docker run -e COMPOSER_CACHE_DIR=/cache -v $(pwd)/cache:/cache - 路径里不能带英文双引号：
COMPOSER_CACHE_DIR="/path/with space"是错的——要么避免空格，要么用符号链接绕过
cache-vcs-dir 必须单独配，否则 Git 包还是重复克隆
cache-vcs-dir 和 cache-dir 是两套独立路径，前者专管 Git/SVN 克隆副本，不配它，composer require "git@github.com:xxx/yyy" 这类 VCS 依赖每次都会重 clone：
- 运行
composer config --global cache-vcs-dir "/home/user/composer-vcs-cache"（建议绝对路径） - 确保该路径有读写权限，且磁盘空间充足（Git 克隆副本通常比 dist 包大得多）
- 配完后，多个项目引用同一个 GitHub 仓库时，只会 clone 一次，后续全走本地复用
- CI 环境中效果尤其明显：可减少 40%+ 的 Git 操作耗时
缓存目录本身容易被忽略的三个硬性条件
即使路径设对了，缓存也未必真起效：
- 目录必须存在，且当前用户有
rwx权限（Linux/macOS 下缺x权限会导致进不去目录） - 不能挂载在 NFS、Docker volume 或受限磁盘上——内核可能静默拒绝写入，错误藏在 verbose 日志里：
file_put_contents(): failed to open stream: Permission denied - 路径最好落在 SSD 上，比如
/mnt/ssd/composer-cache；放在机械盘或网络盘上，解压 zip 包时 I/O 成瓶颈，缓存反而拖慢整体速度
真正难的不是设路径，而是让所有缓存层级（dist、VCS、metadata）都落到同一块高速、可写、隔离的磁盘上，并确保没有残留的 config 冲突项干扰运行时解析。
