Composer 在 Monorepo 中依赖根 composer.json 的 repositories 手动配置 path 仓库，路径须为相对根目录的精确匹配（如 "packages/utils"），子包需含合法 name 字段，require 名称须完全一致，启用 symlink 需显式配置 "options": {"symlink": true}，且每次修改后必须执行 composer clear-cache。
Composer 本身不识别 Monorepo，所有「本地包能装上、能联动、能实时改代码」的效果，全靠你在根 composer.json 里手动骗它——告诉它：“这些目录就是合法包源”，且必须写对路径、名字、版本和选项。
path 仓库必须写在根 composer.json 里，且 url 是相对路径
子包（比如 packages/utils）自己的 composer.json 再规范也没用，Composer 根本不会主动扫描子目录。只有根目录的 composer.json 中 repositories 配置了，它才去查。
-
url必须是相对于根目录的路径，例如"packages/utils"或通配"packages/*"（注意：不支持**递归匹配） - 绝对路径（如
/home/user/project/packages/utils）会导致协作失败——别人机器上路径不同，composer install直接报错 - 若子包在
packages/core/v2，不能指望"packages/*"自动命中，得显式加一条"packages/core/v2" - 每个匹配到的目录下，必须有合法的
composer.json，且含"name"字段（如"myorg/utils"），否则该路径被跳过
require 的包名必须和子包 composer.json 的 name 完全一致
大小写、斜杠方向、连字符都敏感。写错一个字符，Composer 就当它不存在，转头去 Packagist 找同名包，或者报 could not find package。
-
"myorg/utils"≠"MyOrg/Utils"≠"myorg\utils" - 版本约束别混用：
"dev-main"、"*@dev"、"*"都行；但写"^1.0"就危险——Composer 会优先选 Packagist 上已发布的 1.x 版本，跳过你本地改的代码 - 改完子包的
composer.json或根的repositories后，务必先运行composer clear-cache，否则可能读缓存导致识别失败
符号链接（symlink）不是默认总生效，得显式控制
预期是 vendor/myorg/utils 指向 packages/utils，结果却是复制了一份——说明软链没建成功，Composer 退化为 copy 模式。
- Windows 用户需确认终端是否以管理员身份运行，或已启用“开发者模式”（否则
mklink被禁用） - Linux/macOS 上若仍失败，检查
vendor/所在文件系统是否挂载了noexec或nosymfollow - 最稳妥方式：在
path仓库配置中加"options": {"symlink": true}，强制启用（2026 年主流 Composer 版本均支持） -
--no-dev或COMPOSER_HOME权限问题也可能导致 symlink 失效
子包之间互相依赖时，所有被依赖项都得进 repositories
比如 user-service require data-validator，而 data-validator 又 require core-utils——这三层依赖，只要有一层没被 repositories 覆盖，Composer 就无法解析，要么报错，要么装错远程版本。
- 别只配一级路径（如只写
"packages/*"却漏了"apps/*"），推荐统一用多条通配："packages/*"+"apps/*" - 如果子包在
packages/core/v2，但repositories只写了"packages/core"，那它不会被识别——通配不递归，必须精确匹配目录层级 - 执行更新时，别只信
composer dump-autoload：它只刷新自动加载映射，不触发包内容同步；要用composer update myorg/data-validator --with-dependencies，或干脆删掉vendor/myorg/data-validator再composer install
Monorepo 下的 Composer 管理，本质是一场和缓存、路径、大小写、权限和版本约束的持续周旋。最容易被忽略的是：每次改完配置或子包定义，不清理缓存就重试，几乎必然失败。
