最稳方式是设composer_cache_dir环境变量，优先级最高；确认真实生效路径应执行composer global show -v查cache directory行，而非仅看config --global输出。
直接改 COMPOSER_CACHE_DIR 环境变量最稳，优先级最高，不依赖配置文件，CI/CD 和多用户场景下不会被覆盖。
怎么确认当前缓存路径正在生效
别只看 composer config --global cache-dir 的输出——它只显示配置值，不一定真实生效。真正起作用的是运行时解析后的路径：
- 执行
composer global show -v，找输出里Cache directory:那一行，这才是 Composer 实际在用的路径 - 或者跑一次
composer install（哪怕项目已装好），然后立刻检查目标缓存目录下是否有新生成的archived/或repo/子目录 - 如果用了环境变量但没生效，大概率是
composer config --global cache-dir之前设过值，而你没清掉——运行composer config --global --unset cache-dir再试
用 COMPOSER_CACHE_DIR 设置路径的实操要点
这个环境变量是唯一能“强制覆盖”所有其他配置的方式，但写法和权限容易出错：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Linux/macOS：在
~/.bashrc或~/.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"是错的——要么避免空格，要么用符号链接绕过
为什么改了路径却没写入缓存
Composer 静默失败是常态，根本不会报错，只会退化成无缓存模式反复拉包：
- 目标目录不存在，或当前用户无
rwX权限（Linux/macOS 下尤其注意execute权限，否则进不去目录） - 路径挂载在 NFS、Docker volume 或受限磁盘上，写操作被内核拒绝（
file_put_contents(): failed to open stream: Permission denied这类错误可能藏在 verbose 日志里） - CI 环境中设了
COMPOSER_CACHE_DIR却没挂载持久卷，每次构建都是空目录，等于白设 - 用 root 跑过一次
composer global require，之后切回普通用户，旧缓存目录属主是 root，新用户写不进去
改完要不要清理旧缓存
要，但不是为了“腾空间”，而是防止混用导致行为异常：
- 新旧缓存目录同时存在时，Composer 可能从旧目录读元数据、往新目录写包，造成 hash 不一致或解压失败
- 运行
composer clear-cache只清当前生效路径下的内容；旧路径得手动删，比如rm -rf ~/.composer/cache - 如果你把缓存移到 SSD 或 RAM 盘，记得提前
mkdir -p /path/to/new/cache && chmod 755 /path/to/new/cache，再设环境变量
最常被忽略的一点：缓存路径改了，但 CI 脚本里还在 rm -rf ~/.composer，结果新缓存完全没被清理，旧缓存又早被删光——整个缓存机制就失效了。
