换镜像不能解决依赖解析慢的问题，真正拖慢安装的是Composer对path仓库、monorepo结构或未优化autoload的重复解析行为，尤其在“Loading composer repositories”阶段大量I/O扫描本地目录及元数据合并。
换镜像本身不能解决依赖解析慢的问题，它只加速下载；真正拖慢组件库安装的，是 Composer 对本地 path 仓库、monorepo 结构或未优化 autoload 的重复解析行为。
为什么换镜像后 install 还是卡在 “Loading composer repositories”
这个阶段根本没开始下载包，而是在读取和合并所有 repositories 配置、解析每个源的 packages.json 并构建元数据缓存。如果你的项目用了 path 类型仓库（比如 monorepo 中的 "packages/utils": {"type": "path", "url": "./packages/utils"}），Composer 会逐个扫描对应目录下的 composer.json，触发大量文件 I/O 和 symlink 判断——这和镜像源完全无关。
- 执行
composer install -vvv，看到卡在Loading composer repositories超过 10 秒，基本可判定是本地仓库或锁文件过大导致 - 临时注释掉
composer.json中的repositories字段再试一次，如果明显变快，问题就出在本地源上 - 确认是否启用了已废弃插件（如
hirak/prestissimo），它们会在解析阶段注入额外钩子，反而拖慢流程
monorepo 场景下 path 仓库必须关掉的两个 config 项
在根 composer.json 的 "config" 段里显式设置以下两项，能直接砍掉 60%+ 的解析耗时：
-
"fxp-asset": false：禁用对 Bower/NPM 包的自动探测，否则每个path目录都会被额外 HTTP 请求试探 -
"preferred-install": "dist"：强制所有非path包走 zip 下载，避免 Git clone 占用解析线程（注意：该配置对path无效，但能减少干扰）
别写进全局配置——这些是项目级行为控制，写在 config 里才生效。漏掉任一都可能让 Composer 在几十个本地包之间反复校验版本约束。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
验证镜像是否真在用，别信 composer config -g repo.packagist 的输出
这条命令只告诉你“你写了什么”，不反映实际请求路径。真正有效的验证方式只有两种：
- 加
-vvv执行一次真实操作：composer clear-cache && composer require monolog/monolog -vvv 2>&1 | grep "Downloading.*packages.json"，确认日志里出现的是mirrors.aliyun.com/composer/packages.json，而不是repo.packagist.org或packagist.org - 运行
composer diagnose，看输出中Repo packagist.org:后面是不是你设的地址；如果还是显示https://repo.packagist.org，说明被项目级repositories覆盖了，或者 URL 少了末尾斜杠导致静默回退
尤其要注意：URL 必须带末尾 /，https://mirrors.aliyun.com/composer/ ✅，https://mirrors.aliyun.com/composer ❌——后者在 Composer 2.2+ 会 404，然后自动 fallback 到官方源，整个过程不报错，你只会觉得“怎么还是慢”。
大型组件库项目必须清理的三个锁文件冗余点
composer.lock 不只是版本快照，它还存了每个包的完整 dist checksum、source commit、require-dev 列表等。组件库多、私有包多的项目，lock 文件很容易膨胀到 5–10MB，光是 JSON 解析就要 2–3 秒。
- 删掉长期不用的
require-dev工具，比如旧版phpstan/phpstan、已迁移走的phpunit/phpunit版本——它们不安装，但仍在 lock 中参与解析 - 给所有私有包声明
"archive": {"exclude": ["/tests", "/docs", "/examples"]}，否则 lock 会记录这些路径的 hash，徒增体积 - 定期运行
composer update --lock（不带包名），它会压缩 JSON 格式、合并重复字段、剔除已失效的元数据
最常被忽略的是：已有 composer.lock 的项目首次切镜像后，大概率因 hash 不匹配失败；此时不要硬扛，删掉 vendor/ 和 composer.lock 再 install 更省时间。
