根本原因是Composer在Monorepo中默认逐个扫描path仓库目录、读取composer.json并校验symlink，导致I/O与逻辑开销剧增；必须配置"fxp-asset": false和"preferred-install": "dist"，并使用"@dev"等本地引用方式，否则安装将从几秒延长至数分钟。
Composer 本身不支持 Monorepo，所谓“优化”不是加功能，而是规避它在多 path 仓库场景下的默认行为缺陷——否则 composer install 会从几秒拖到 3–5 分钟，且改一个包、全量重装。
为什么 composer install 在 Monorepo 里卡在 “Loading composer repositories”
这不是网络慢，是 Composer 正在逐个扫描所有 repositories 中的 path 目录，读取每个子包的 composer.json，校验 symlink 权限、判断是否可软链、合并元数据……几十个包叠加，I/O + 逻辑开销爆炸。
- 执行
composer install -vvv，如果卡在Loading composer repositories超过 8 秒，基本就是本地path仓库惹的祸 - 临时注释掉根
composer.json中的repositories字段再跑一次，耗时明显下降 → 确认问题源 - 别信“换镜像就能快”，这个阶段根本没发起任何 HTTP 请求
path 仓库必须显式配置的两个 config 项
这两项不写进根 composer.json 的 config 段，60%+ 的解析耗时就省不下来：
-
"fxp-asset": false：禁用对 Bower/NPM 包的探测，否则每个path目录都会被额外试探一次 HTTP -
"preferred-install": "dist"：强制非path包走 ZIP 安装，避免 Git clone 占用解析线程（注意：它对path无效，但能减少干扰）
漏掉任一，Composer 就会在几十个本地包之间反复做版本约束比对和远程 fallback 判断。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
require 中的版本写法错一个字符就加载远程包
写 "acme/utils": "^1.0" 或 "acme/utils": "1.2.3"，Composer 就直接跳过本地目录，去 Packagist 找已发布的版本——不报错，但你改的代码永远不生效。
- 正确写法只有
"acme/utils": "@dev"、"acme/utils": "dev-main"或"acme/utils": "*@dev" - 子包
composer.json中的name必须和require键完全一致：大小写、连字符、斜杠方向全部敏感 -
url必须是相对于根composer.json的精确路径，不能带./，也不能用通配符（如"packages/*"）除非你确认用的是 Composer 2.2+ 且每个子目录都有合法composer.json）
symlink 没建成功？先检查这三件事
预期 vendor/acme/utils 是指向 packages/utils 的软链，结果却是完整复制 —— 这说明 symlink 已退化为 copy 模式，Monorepo 开发效率直接归零。
- 在
repositories条目中显式加"options": {"symlink": true}（仅 Composer 2.2+ 支持，2.9.6 已稳定） - Windows 用户需以管理员身份运行终端，或开启「开发者模式」；Linux/macOS 检查
vendor/所在文件系统是否挂载了noexec或nosymfollow - 软链建好后仍不生效？删掉
vendor/acme/utils目录，再跑一次composer install—— 缓存可能残留旧状态
最隐蔽的坑不是配置错，而是改完 repositories 没清缓存：composer clear-cache 必须每次调整后都执行，否则路径失效静默发生。
