镜像配置没生效的根本原因是配置格式错误，必须同时满足键名repo.packagist、type为"composer"、url为https且末尾带/；清缓存无效时需验证配置、确认缓存路径、清理repo/目录及composer.lock，并用--no-cache重装。

镜像配置没生效，清缓存根本没用

执行 composer clear-cache 后 composer install 依然卡在 Loading composer repositories，大概率不是缓存问题，而是镜像压根没配对。Composer 2.x 对配置格式极其敏感，漏掉任意一项就会静默回退到 https://packagist.org。

必须同时满足这三点：

• composer config -g repo.packagist 中的键名是 repo.packagist（不是 repos.packagist 或 packagist.org）
• type 值必须显式为 "composer"（不能省略、不能写成 composer-type）
• url 必须是 HTTPS 且末尾带 /，例如 https://mirrors.aliyun.com/composer/（少斜杠会拼出错误路径导致 404）

验证是否成功：运行 composer config -g repo.packagist，输出应为 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 或纯 URL 字符串。空、null、或仍是官方地址，说明配置失败。

缓存清理前必须确认路径和占用

composer clear-cache 只清 composer config --global cache-dir 返回的那个目录，不保证是 ~/.composer/cache——公司 CI 环境常通过 COMPOSER_CACHE_DIR 挂到 NFS，清错位置等于白干。

先查真实路径和大小：

• Linux/macOS：composer config --global cache-dir → 再执行 du -sh $(composer config --global cache-dir)
• Windows：打开资源管理器，粘贴 %APPDATA%\Composer\Cache，右键“属性”

不到 200 MB 别清；超 1.5 GB 且半年没碰老项目，才值得动手。如果路径显示 /mnt/nfs/composer-cache，说明缓存不在本地磁盘，清它可能影响其他构建节点。

清完缓存仍装旧包？真凶在 composer.lock 和 repo/ 目录

composer clear-cache 只删 ~/.composer/cache/files/、repo/、vcs/，它不碰 composer.lock 和 vendor/composer/installed.json。锁文件固化了版本哈希，缓存再干净也拉不到新版。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

换镜像后想重装最新版，必须手动清理三处：

• ~/.composer/cache/repo/https---packagist.org/（或对应私有源路径）：这里存着 packages.json 和 provider-*.json，决定你能看到哪些版本
• vendor/composer/installed.json：记录当前已安装包的精确版本和 source 类型，影响依赖解析上下文
• composer.lock：不是缓存，但它是“版本事实”的唯一权威

删完这三项，再跑 composer install --no-cache（注意是 --no-cache，不是 clear-cache），才能强制跳过所有本地快照，直连远程重新拉取元数据和包。

CI/CD 里 composer clear-cache 默认会卡住

GitHub Actions、GitLab CI 等无 TTY 环境下，composer clear-cache 默认等待用户输入 y/n，不加参数就是死等。

预检用：composer clear-cache --dry-run —— 只输出将删的路径，不删文件，确认是否指向预期位置

真正执行加：composer clear-cache --no-interaction

如果仍卡住，可能是后台有 composer install 进程锁着缓存目录：

• Linux/macOS：lsof +D $(composer config --global cache-dir)
• Windows：handle.exe -p php.exe vcs/

缓存清理本身不解决依赖解析慢的问题，它只解决元数据陈旧、包文件损坏或镜像未同步这类场景。真正拖慢 composer update 的，往往是锁文件未更新、dev 依赖未跳过、或 PHP 自身内存限制被 Composer 主动覆盖——这些点比缓存更关键，也更容易被忽略。