根本原因不是网络卡顿，而是Composer在monorepo中逐个扫描本地path仓库并执行realpath()、is_dir()等I/O操作，叠加symlink判断导致耗时激增；需禁用fxp-asset插件、设preferred-install为dist，并启用lock-file-version:2格式。
为什么“换了镜像还卡在 Loading composer repositories”
这个阶段根本没走网络，不涉及镜像源，而是 Composer 在扫描所有 repositories 配置项下的本地路径——尤其当你的 composer.json 里写了十几个 "type": "path" 仓库时，它会逐个 realpath()、is_dir()、file_get_contents("./packages/foo/composer.json")，I/O 和 symlink 判断叠加起来，几十毫秒变几秒甚至十几秒。
常见错误现象：composer install -vvv 日志开头卡在 Loading composer repositories 超过 5 秒，且后续没出现任何 Downloading 行；临时注释掉 repositories 段再试，速度立竿见影。
- 别信
composer config -g repo.packagist的输出——它和这个阶段完全无关 - monorepo 场景下，
path仓库越多，耗时越非线性增长 - 废弃插件如
fxp/composer-asset-plugin会在该阶段注入额外钩子，直接拖慢 2–3 倍
monorepo 必关的两个 config 项
在根 composer.json 的 "config" 字段里显式写死这两项，能砍掉 60%+ 的解析时间。它们不是可选优化，是 monorepo 下的刚需：
-
"fxp-asset": false：禁用对 Bower/NPM 包的探测逻辑，否则每个path目录都会触发一次 HTTP 请求试探（哪怕你根本不用前端包） -
"preferred-install": "dist"：强制非path包走 ZIP 安装，避免 Git clone 占用解析线程（注意：该配置对path无效，但能减少干扰）
漏掉任一，Composer 就会在几十个本地包之间反复校验版本约束、试探 dist vs source、检查 symlink 状态——这些动作全在单线程里串行执行。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
锁文件大 + 解析慢的真实瓶颈在哪
大型 monorepo 的 composer.lock 文件动辄数 MB，但真正拖慢的不是文件大小本身，而是 Composer 2.2+ 之前默认使用的 lock-file-version: 1 格式：冗余字段多、JSON 层级深、PHP json_decode() 解析耗时高。
- 确认是否启用新版格式：
composer.json中必须有"lock-file-version": 2 - 若没生效，运行
composer update --lock（不改依赖，只重写 lock）或删掉composer.lock后composer install - CI 中避免每次构建都重生成 lock：只在
composer.json变更时才跑composer update，其余一律composer install --no-interaction --prefer-dist
升级到 Composer 2.5+ 后，lock 解析器已重构为流式读取，对 10MB+ lock 文件的内存占用和 CPU 时间下降明显——别卡在 2.1.x。
Docker/CI 环境里镜像配置总失效的根因
你在本地终端配好了镜像，但宝塔后台、GitLab Runner 或 Docker 构建时依然慢，90% 是因为用户权限错位或缓存未清：
- 全局配置只对当前 shell 用户生效；CI 用
runner用户、宝塔用www用户，得用对应用户重配：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 容器内不能依赖宿主机
~/.composer/config.json——它不会透传，必须在Dockerfile的RUN阶段写入 - 换镜像后必须
composer clear-cache，否则旧缓存仍走packagist.org - 验证是否真生效：跑
composer install -vvv 2>&1 | grep "Downloading.*packages.json"，看域名是不是mirrors.aliyun.com
monorepo 的复杂性在于：它把本地 I/O、锁文件解析、远程下载三类瓶颈全堆在一起，任何一个环节松动，整体就卡住。最容易被忽略的是 fxp-asset 和 preferred-install 这两个 config——它们不报错，但会让 Composer 在几十个 path 目录里默默多做几百次文件系统调用。
