Composer本地path仓库需在主项目composer.json顶层repositories声明路径，包名和version须匹配且禁用Packagist源以防冲突；成功后vendor中为符号链接，修改源码即热更新，但改composer.json需dump-autoload。
本地扩展包怎么用 path 仓库类型
Composer 支持通过 path 类型仓库直接加载本地文件系统中的包，不需要发布到 Packagist 或私有服务器。这适用于你正在开发一个扩展包（比如 mycompany/laravel-widget），同时在另一个项目里调试它。
关键点是：必须在主项目的 composer.json 中显式声明该路径仓库，并确保被引用包的 composer.json 里有合法的 name 和 version（哪怕写 "dev-main"）。
- 在主项目根目录的
composer.json的repositories字段添加：
{
"repositories": [
{
"type": "path",
"url": "../mycompany-laravel-widget"
}
]
}
-
url是相对于当前composer.json文件的路径，支持../、./packages/xxx等写法 - 执行
composer require mycompany/laravel-widget:@dev（注意版本需匹配被引用包中version或分支名） - 成功后，
vendor/mycompany/laravel-widget会是一个符号链接（Linux/macOS）或 junction（Windows），指向你本地源码目录
为什么 require 后没生成软链，反而下了 zip 包？
这是最常踩的坑：Composer 默认优先走 Packagist，即使你加了 path 仓库，只要包名在 Packagist 上存在，它就会忽略本地路径，去下载远程版本。
- 检查是否误写了包名——比如你想引用
myorg/utils，但 Packagist 上已有同名包，Composer 就不会用你的path - 确认
repositories块写在主项目composer.json顶层，不是嵌套在extra或其他字段里 - 运行
composer clear-cache再试；必要时加-vvv查看 Composer 实际解析了哪些仓库 - 临时把 Packagist 官方源禁掉可验证：
composer config --file composer.json repo.packagist false
path 仓库下如何热更新代码而不重装？
因为 path 模式本质是符号链接，修改本地源码后，主项目里立刻可见，无需 composer update。但有几个边界情况要注意：
- 如果改了被引用包的
composer.json（如新增autoload规则），需要运行composer dump-autoload在主项目中刷新自动加载映射 - 如果删了本地包目录再重建，符号链接会断开，此时需
composer update mycompany/laravel-widget重新建立链接 - Windows 下若提示 “junction point” 权限错误，以管理员身份运行终端，或改用
composer config --global use-include-path true配合手动require
和 symlink 方式比，path 仓库有什么实际区别？
有人会直接在 vendor 里手动 ln -s，但这绕过了 Composer 生命周期管理，隐患明显：
- 手动软链不参与
composer install --no-dev的依赖裁剪逻辑，dev-only 包可能意外残留 -
composer outdated、composer show等命令无法识别手动链接的包，查版本、依赖关系都失效 - CI 环境或团队协作时，别人
composer install会失败，因为没你本地的路径 -
path仓库是声明式的，配合.gitignore忽略vendor/后，所有协作者只要 clone 主项目 + 本地有对应路径，就能一致工作
真正麻烦的不是配置，而是路径写错、包名不一致、或者忘了关 Packagist 源——这些地方一卡，就容易怀疑是不是 path 本身有问题。
