用 path 仓库可本地加载扩展包，需在项目 composer.json 中配置 repositories 指向本地路径（推荐相对路径如 ../my-package），本地包需有合法 name 和 version；执行 composer require 后生成软链接（Linux/macOS）或复制（Windows），修改实时生效。
composer 加载本地扩展包：用 path 仓库最直接
本地开发的扩展包，不需要发布到 Packagist，path 类型仓库就能让 Composer 当作远程包一样安装和更新。它本质是软链接（Linux/macOS）或复制（Windows），不走 Git 克隆，也不依赖版本号解析。
常见错误现象：composer require vendor/name 报错 Could not find a matching version，是因为没声明仓库，Composer 根本不知道包在哪。
- 在项目根目录的
composer.json中添加repositories字段，指向本地包路径 - 路径必须是绝对路径或相对于
composer.json的相对路径（推荐用相对路径，如../my-package） - 本地包自己的
composer.json必须有合法的name和version（或使用"dev-main"这类分支别名） - 执行
composer require vendor/name后，Composer 会在vendor/下创建符号链接（非 Windows）或硬拷贝（Windows），修改本地源码会实时生效
引用本地项目源码：避免 symlink 权限问题的替代方案
Windows 或某些 Docker 环境下，path 仓库生成的 symlink 可能失效或被忽略，导致代码不更新、调试断点不触发。
这时更稳妥的做法是用 composer install --no-dev + 手动 autoload 注入，绕过 vendor 链接逻辑。
- 把本地项目目录放在项目同级（如
../my-app），确保其composer.json有"autoload": {"psr-4": {...}} - 在主项目的
composer.json的autoload段里追加对应命名空间映射，例如："MyApp\": "../my-app/src/" - 运行
composer dump-autoload生效，无需require，也不进vendor - 注意：这种方式下，
composer update不会影响该路径，更新靠手动同步；且无法使用该包的require-dev或脚本
为什么不能只改 vendor 里的代码？
直接编辑 vendor/vendor/name 下的文件看似快，但下次 composer update 或重装就会被覆盖，协作时其他人根本看不到你的修改。
更隐蔽的问题是：Composer 的 autoloader 缓存（如 vendor/composer/autoload_classmap.php）可能没刷新，导致旧逻辑还在跑。
- 所有临时修改都应通过
path仓库或autoload映射落地 - 如果只是想快速验证某行改动，可用
composer install --no-scripts --no-plugins防止自动清理 - CI/CD 流程中，
path仓库会被忽略（默认只读 Packagist），上线前必须切回真实版本或打包发布
Windows 下 path 仓库的坑：不是所有路径都认
Windows 用户常遇到 Invalid argument 或链接失败，根源是 Composer 对 .. 路径解析不稳定，尤其跨盘符（如 C: → D:）时。
实测可靠写法只有两种：
- 用正斜杠且不跨盘符：
"../my-package"（推荐） - 用绝对路径并统一用正斜杠：
"D:/projects/my-package"（反斜杠会导致 JSON 解析失败） - 避免混合写法，如
"..my-package"或"C:\projects\my-package" - 若仍失败，检查本地包根目录是否有
composer.json，且无语法错误（composer validate可验）
composer install 阶段，不是运行时。路径写错不会报错，而是静默跳过——这是最容易被忽略的点。 
