composer拉本地path包需在根项目composer.json显式配置repositories且类型为path，name、路径、版本必须严格匹配，启用symlink后修改即生效，嵌套依赖须全部在根项目注册。
path仓库怎么配才让composer install拉到本地代码
必须在根项目的composer.json里显式声明repositories，且类型为path，不能只靠require就生效。
常见错误是只写了"my/package": "dev-main"却没配repositories，结果Composer仍从Packagist下载远程包，本地修改完全不生效。
- 路径必须是相对当前
composer.json的绝对路径或相对路径（推荐用../packages/my-package这类） - 被引用的本地包自身
composer.json里name字段要和根项目require中的名字完全一致（包括大小写） - 路径末尾加
/*可启用自动发现（如"url": "../packages/*"），但要求每个子目录都是合法包结构
为什么composer update不更新本地path包的代码
因为path仓库默认启用symlink软链接，Composer不会复制文件，而是直接挂载源目录。所以改了本地代码，不需要重装或更新——下次require就直接生效。
但这也意味着：如果本地包目录被移动、删除，或者你执行了composer install --no-dev又清了vendor，软链接会断掉，报错failed to open stream: No such file or Directory。
- 确认是否真用了symlink：进
vendor/my/package看是不是个链接（macos/linux用ls -l，windows用dir） - 想强制复制而非链接？在
repositories里加"options": {"symlink": false} -
composer dump-autoload通常就够了，不用动update
多个本地模块互相依赖时path怎么嵌套写
不能在一个path包的composer.json里再写repositories——子包的依赖解析由根项目统一控制，子包里的repositories会被忽略。
所有本地路径都得在根项目的composer.json里一次性注册好，否则即使A依赖B，而B是path类型，Composer也会去Packagist找B。
- 根项目
repositories顺序无关，但必须全部列出：A、B、C各自独立注册 - 如果B同时被A和根项目require，只要B的
name和路径对得上，Composer能复用同一个symlink - 避免循环依赖：A require B，B require A → Composer会报
dependency resolution failed
composer install后vendor里没出现path包
最可能的原因是版本约束不匹配。Composer只认require中声明的版本号，而path包的version字段（或branch-alias）必须满足该约束，否则跳过加载。
比如根项目写"my/package": "^1.2"，但本地包composer.json里是"version": "dev-main"，Composer就不认——它需要明确的稳定版本或带dev-前缀的开发分支名。
- 临时解法：把本地包
version改成"dev-main as 1.2.99"，或require写成"my/package": "dev-main" - 更稳的做法：用
branch-alias在extra里声明别名，例如"dev-main": "1.2.x-dev" - 运行
composer show my/package能立刻看到Composer实际解析出的版本和来源
真正卡住的时候，往往不是配置写错了，而是name拼错、路径权限不对、或者版本字符串没对上——这些地方没法靠报错信息一眼看出，得一个个手动核对。