path类型仓库用于本地开发测试，可将本地目录作为Composer包引用，适用于私有包调试、团队共享组件开发、集成未发布包及符号链接优化，提升迭代效率与协作便利性。
Composer 中的 path 类型仓库主要用于本地开发和测试，它允许你将本地文件系统中的一个目录当作一个 Composer 包来引用。这种机制在实际开发中非常实用，尤其适用于以下几种场景：
1. 本地开发和调试私有包
当你正在开发一个 PHP 组件或库，并希望在另一个项目中测试它时，使用 path 仓库可以避免频繁提交到远程仓库或发布到 Packagist。
例如，你在本地有一个工具库 /home/user/my-lib，同时有一个主项目依赖它。通过配置 path 仓库，主项目可以直接加载这个本地目录作为依赖，修改后立即生效，无需打包或推送。
- 加快开发迭代速度
- 支持实时修改和调试
- 避免因版本号问题导致缓存困扰
2. 团队协作中的共享组件开发
在团队开发中，多个项目可能共用同一个内部组件。通过 path 映射，团队成员可以在本地同步开发主项目和组件，确保接口兼容性。
比如，前后端分离项目中，API 项目依赖一个本地的“业务逻辑层”包。开发者可以同时打开两个项目，在 IDE 中直接跳转函数定义，提升协作效率。
- 便于联调和接口对齐
- 减少因网络或权限导致的依赖拉取失败
- 适合配合符号链接（symlink）实现文件同步
3. 集成未公开发布的包
有些公司内部的组件不会发布到公共仓库，也不希望通过私有 Packagist 管理。此时可以直接用 path 指向本地路径，简化部署流程。
尤其是在 CI/CD 流水线之外的临时测试环境中，可以直接挂载目录并启用 path 引用，快速验证功能。
4. 支持符号链接（symlink）的开发优化
当 path 仓库设置 "symlink": true 时，Composer 会创建符号链接而不是复制文件。这样两个项目共享同一份源码，节省磁盘空间，也保证修改即时反映。
这在大型项目中特别有用，比如 Laravel 扩展包开发、Symfony Bundle 调试等。
- 节省重复复制的成本
- 保持源码一致性
- 适合与 Docker 开发环境结合使用（通过卷挂载）
基本上就这些。path 仓库不是为生产环境设计的，但在开发阶段能极大提升效率，关键是用好 symlink 和本地路径管理。不复杂但容易忽略。
