ci/cd 中应在依赖安装前、vendor 目录重建前执行 composer clear-cache --no-interaction，作为独立步骤置于 rm -rf vendor 之前或紧随其后；必须设置 composer_cache_dir（如自定义）并确保生效，且不可依赖 post-install-cmd，因 ci 通常启用 --no-scripts 导致其不执行。
CI/CD 流程里该在哪一步执行 composer clear-cache
它不该放在 composer install 之后，也不该塞进 post-install-cmd；真正起效的位置是依赖安装前、且 vendor 目录尚未重建时。
常见错误是把清理当“兜底操作”——等构建失败了再补一条 composer clear-cache，结果发现缓存早被复用、旧包已解压进 vendor/composer/archives/，清完全局缓存也没用。
- GitHub Actions / GitLab CI 中，应作为独立步骤放在
rm -rf vendor之前或紧随其后（先清全局缓存，再删 vendor 更稳妥） - 若使用自定义缓存路径（如
COMPOSER_CACHE_DIR=/mnt/cache/composer），必须在clear-cache前确保该环境变量已生效，否则清的是空目录 - 不要依赖
"post-install-cmd": "composer clear-cache"—— CI 通常加--no-scripts，这条根本不会跑 - 在 Docker 构建中，
RUN composer clear-cache --no-interaction应放在WORKDIR设置后、COPY composer.* .之前，避免误清构建中间层缓存
composer clear-cache --no-interaction 为什么不能省略参数
因为默认行为会输出 Cache directory: /home/user/.composer/cache 后停住，等待用户敲回车确认——这在无 TTY 的 CI 环境里直接卡死，后续步骤全挂。
这不是可选优化，而是硬性要求。漏掉 --no-interaction 是 CI 构建超时最常见原因之一。
-
composer clear-cache本身不支持-n缩写，必须写全--no-interaction - 某些旧版 Composer（--no-interaction 支持不稳定，建议搭配
composer self-update --2升级到 Composer 2.x - Windows 环境下若用 cmd 执行（非 PowerShell），
--no-interaction依然有效，但注意路径分隔符不影响该参数
清完缓存为什么还装旧版本？关键在 composer.lock 和 vendor 残留
composer clear-cache 只动 ~/.composer/cache，完全不管 composer.lock 和 vendor/。所以清完立刻 composer install，照样还原锁文件里的旧版本——这不是命令失效，是设计如此。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
真正影响安装结果的，是这三样东西的组合状态：
-
composer.lock存在 →install必走锁文件，和缓存无关 -
vendor/目录残留 → 尤其vendor/composer/archives/里有旧 zip，install可能跳过下载直接解压 - 镜像源 CDN 缓存未刷新 →
clear-cache清不了阿里云/腾讯云服务器上的packages.json快照
所以自动化脚本里，真要确保装新包，得配齐这三步：composer clear-cache --no-interaction + rm -rf vendor composer.lock + composer install --no-cache（注意是 --no-cache，不是 clear-cache）。
Windows 和 WSL 2 下的特殊处理点
在 WSL 2 里执行 composer clear-cache 是安全的，但要注意：Windows 主机上通过资源管理器手动删过 %APPDATA%\Composer\Cache，可能导致 WSL 2 里 composer config --global cache-dir 返回路径与实际不符。
更麻烦的是权限错位——比如 WSL 2 以 root 运行，而缓存目录属 Windows 用户所有，clear-cache 会静默跳过删除。
- 始终用
composer config --global cache-dir查当前真实路径，别猜 - WSL 2 中避免混用 Windows 的 Composer 安装（如 Composer-Setup.exe），统一用 Linux 方式安装（
curl -sS https://getcomposer.org/installer | php） - Windows 原生环境要用
del /q "%APPDATA%\Composer\Cache\*"替代rm -rf，且需管理员权限才能删C:\ProgramData\ComposerSetup\Cache类路径
最容易被忽略的是：缓存路径可能被 CI 工具（如 Jenkins agent）或容器运行时（如 Podman）覆盖，clear-cache 执行前后查一次 composer config --global cache-dir 输出，比盲目信任文档更可靠。
