查当前实际生效缓存路径的唯一可信方式是运行composer diag，看其输出中“cache directory:”一行；composer config --global cache-dir仅显示配置值，可能被环境变量覆盖或因权限问题静默回退到默认路径。
缓存路径管理不靠猜，靠明确控制：全局配置用 composer config --global cache-dir，临时切换必须用 COMPOSER_CACHE_DIR 环境变量，其他方式基本无效或埋坑。
怎么查当前实际生效的缓存路径？别信 config 输出，要看 composer diag
运行 composer config --global cache-dir 只显示配置值，不是真实路径——它可能被环境变量覆盖，也可能因权限/目录不存在而静默 fallback。唯一可信的是 composer diag 的输出里 Cache directory: 那一行。常见误判场景：
- CI 脚本里设了
COMPOSER_CACHE_DIR但没mkdir -p，composer diag还显示你设的路径，实际写入却落到~/.composer/cache - Windows 上配了
%APPDATA%\Composer\cache，但用户权限受限，Composer 自动退到临时目录，diag不提示 - 用 root 运行 CI 容器时，
~指向/root，而/root/.composer/cache可能被挂载为只读，导致缓存失效
COMPOSER_CACHE_DIR 临时覆盖的实操要点
这是 CI、Docker、单次调试唯一靠谱的方式，优先级高于所有配置。但它很“脆”，稍有不慎就失效：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 路径必须是绝对路径，不能含
~或变量（如$HOME） - 必须提前
mkdir -p /path/to/cache并确保当前用户有读写权限 - Linux/macOS 下注意 SELinux 或容器安全策略是否拦截写入
- PowerShell 中要用
$env:COMPOSER_CACHE_DIR="D:\composer-cache"，不是set - 验证是否真生效：除了
composer diag，还可ls -l /path/to/cache/repo/看是否有新 JSON 文件生成
改全局缓存路径后，旧缓存要不要搬？
不需要自动迁移，但得手动处理：
-
composer config --global cache-dir /new/path生效后，新install会往新路径写，旧缓存留在原地不动 - 旧缓存不会被自动清理，也不会被新命令读取——Composer 不跨路径查找
- 如果磁盘空间紧张，可手动
rsync -a ~/.composer/cache/ /new/path/（注意权限），但更推荐清空旧缓存：rm -rf ~/.composer/cache - 某些 CI 平台（如 GitHub Actions）默认缓存
~/.composer/cache，改路径后记得同步更新actions/cache的 key 和 path
缓存大小和过期策略怎么调才不翻车？
两个关键配置项： cache-files-ttl 和 cache-files-maxsize，都通过 composer config --global 设置：
-
cache-files-ttl默认 6 个月（15552000 秒），设太短（如 1 天）会导致频繁重下载；设太长（如 2 年）可能堆积大量废弃包 -
cache-files-maxsize默认 300MiB，建议按团队项目数上调到"1G"或"2G"，单位必须带字母（"1024M"❌，"1G"✅） - 这两个值只影响
composer clear-cache --gc的清理行为，不影响日常使用 - 设了
cache-read-only: true后，install会跳过写缓存步骤，适合只读文件系统，但首次构建会变慢
真正容易被忽略的是路径合法性与权限检查——设了环境变量或配置，不代表 Composer 就真的在往那里写。每次换路径，先 mkdir -p，再 composer diag，最后看磁盘上有没有新文件，三步缺一不可。
