必须先执行composer clear-cache，否则镜像配置无效；因其缓存的repo/元数据（含packages.json快照）控制请求逻辑，不清则Composer仍按旧源拉取，导致404或损坏包。
composer clear-cache 必须先执行，否则镜像配置无效
改完 repo.packagist 配置后仍请求 packagist.org？不是配置没生效，而是缓存里还存着旧源的 packages.json 快照和 ZIP 包。Composer 会优先按缓存里的元数据去拉取，根本不会读新配置。
必须先运行：
composer clear-cache
它清掉三类东西：
-
files/：损坏或不完整的 ZIP 包（比如中断下载留下的半截文件） -
repo/：元数据快照（含所有包的packages.json，这是镜像失效的主因） -
vcs/：Git 裸仓库（单个常占 300–800 MB，且大量小文件易耗尽 inode）
CI 环境（如 GitHub Actions）中务必加 --no-interaction，否则卡在交互提示；若报 Permission denied，说明部分缓存子目录属主是 root（比如曾用 sudo composer），需先运行：sudo chown -R $USER:$USER ~/.composer/cache
repo.packagist 配置写法三要素缺一不可
键名、type 值、URL 结尾斜杠，错一个就静默失效——命令不报错，但 composer install -vvv 日志里依然出现 packagist.org。
正确写法只有这一种：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
注意：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 键名固定为
repo.packagist（单数），不是repos.packagist或repositories -
type值必须是composer（不能写成composer-repository或漏掉） - URL 必须以
/结尾，否则拼出的路径是/composerpackages.json，直接 404 - Windows 用户改完要重开终端，否则环境变量未刷新，
composer config -g repo.packagist查不到新值
只清理过期缓存用 --gc，别误删有效包
日常维护不需要全量清空，composer clear-cache 是“大扫除”，而 --gc 是“智能回收”：
composer clear-cache --gc
它只清理两类东西：
- 超过
cache-files-ttl（默认 6 个月）未被访问的 ZIP 包 - 缓存总大小超限（默认 300MiB）时最旧的文件
这个操作保留所有活跃依赖的缓存，对后续 install 或 update 速度影响最小。适合 CI 流水线定期执行，也适合本地长期开发环境维持缓存健康度。
项目级配置 vs 全局配置的适用场景
全局配置（-g）适合个人开发机，所有项目都走镜像；但企业私有项目或需要发布开源包时，得切回项目级配置，避免污染全局状态。
项目内配置（不带 -g）：
cd your-project<br>composer config repo.packagist composer https://mirrors.aliyun.com/composer/
这样配置只写入当前项目的 composer.json，部署时可随代码一起提交，团队成员无需手动设置。但要注意：发布包前必须先 composer config --unset repo.packagist，否则 Packagist 无法解析依赖。
缓存和配置的耦合比想象中紧——镜像地址变了，缓存却还记着旧地图；配置删了，缓存却还在后台偷偷服务。这两者从来不是独立开关，而是一体两面。
