composer path仓库生效需满足三条件：主项目composer.json顶层repositories配置相对路径（如"../my-package"），本地包含合法composer.json且name与require完全一致（如"acme/utils"），version设为"dev-main"；require必须显式写"acme/utils":"dev-main"，并运行composer update acme/utils而非install。
Composer 的 path 仓库类型到底怎么配才生效
它不是加了就自动找得到包，必须满足三个硬性条件：目录结构合规、composer.json 中的 name 和 version 要与 require 时完全一致、且项目根目录下要有可读的 composer.json。常见错误是本地包目录里漏了 composer.json，或者 name 写成 vendor/name 却在主项目里写成了 vendor/name-dev。
正确做法：
-
repositories必须写在主项目的composer.json顶层，不能嵌套在其他字段里 - 路径用相对路径（如
"../my-package"），且该路径必须指向一个含有效composer.json的目录 - 本地包的
composer.json中name必须是标准格式（如"acme/utils"），且version推荐设为"dev-main"或"dev-master"，避免和 packagist 冲突
为什么 composer install 不拉取 path 包，却报 could not find package
根本原因不是路径错，而是 Composer 在解析依赖时跳过了 path 仓库——因为它默认只在 require 版本约束匹配时才启用。比如你本地包 version 是 "dev-main"，但主项目 require 写的是 "^1.0"，那 Composer 直接忽略该仓库。
解决方式：
- 主项目
require必须显式指定开发分支，例如："acme/utils": "dev-main" - 运行
composer update acme/utils，而不是install；install只读composer.lock，不会重新匹配仓库 - 确认没有其他同名包在 packagist 上存在且版本更“匹配”，否则 Composer 会优先选远端
path 仓库下的包修改后不生效，还要反复 update
这是预期行为：Composer 把 path 包当作 symlink（符号链接）处理，但仅在安装/更新时创建。一旦生成，后续代码改动不会触发自动重载——它不像 Node.js 的 link 那样实时响应。
日常开发建议：
- 保持本地包目录独立，直接编辑其源码，改完立刻在主项目中测试（因为是 symlink，无需重新 install）
- 如果发现没更新，先检查 symlink 是否还存在：
ls -l vendor/acme/utils，挂掉就说明路径失效或权限问题 - 不要手动删
vendor/acme/utils后再install，这会断开 symlink；应执行composer update acme/utils让它重建
多人协作时 path 仓库无法共用怎么办
path 本质是本地路径映射，绝对不可提交到团队仓库——每个人的目录结构不同，硬编码路径会导致别人 composer install 直接失败。
协作方案只有两个可行路径：
- 开发阶段用
path，上线前切回vcs（Git 仓库）并发布稳定 tag，然后把repositories条目删掉，require改成具体版本号 - 团队统一约定本地包存放位置（如都放在项目根目录同级的
packages/下），用相对路径"../packages/utils"，并在 README 里明确说明，但这仍依赖人工对齐
真正健壮的做法，是早一点把包推到私有 Packagist（如 Satis 或 Private Packagist），path 只用于单人快速验证，别让它跨出你自己的机器。
