本地开发可用 Composer 的 path 仓库类型直接加载未发布代码：需在 composer.json 中同时配置 repositories（type: "path"）和 require（版本匹配目标库 version 或 "dev-main"），且目标目录须含合法 composer.json 并配置 autoload。
本地开发时如何用 Composer 加载未发布的代码
直接用 path 仓库类型，就能让 Composer 把你本机某个目录当包来装——不用提交 Git、不用推 tag、甚至不用有 composer.json（但建议有）。关键在于告诉 Composer：“这个包的源不在 Packagist，就在我电脑的某个文件夹里。”
常见错误是只改了 require 却没加仓库配置，结果报错：Could not find package xxx at version yyy。必须同时满足两个条件：声明仓库 + 声明依赖版本。
- 在项目根目录的
composer.json中添加repositories字段，类型设为path -
require里的版本号必须匹配目标库composer.json中的version，或写成"dev-main"/"*@dev"（前提是目标库有autoload和合法结构） - 路径支持相对路径（如
../my-package）和绝对路径（如/Users/me/my-package），但不能带~或环境变量
path 仓库的配置格式和常见陷阱
path 仓库不是插件，是 Composer 原生支持的类型，但配置稍不注意就会静默失效。最典型的坑是路径指向了空目录、或目标目录里没有有效的 composer.json —— 此时 Composer 不报错，只是跳过该仓库，继续去 Packagist 找包，最终失败。
正确配置示例如下：
{
"repositories": [
{
"type": "path",
"url": "../my-utils"
}
],
"require": {
"acme/my-utils": "dev-main"
}
}
-
url必须是目录路径，不是composer.json文件路径 - 目标目录（如
../my-utils）里必须存在composer.json，且至少包含name和autoload（否则自动加载会失败） - 如果目标库用了
dev-main，它的composer.json中version字段可省略，但分支名必须真实存在（Git 里真有main分支） - Windows 下路径分隔符用
/或\都行，但推荐统一用/避免转义问题
为什么 require 后没生成 autoload？
即使 composer install 成功，也可能发现新包的类根本无法 use —— 大概率是目标库的 composer.json 缺少 autoload 配置，或者路径映射写错了。
比如目标库想暴露 src/ 下所有类，它的 composer.json 必须有：
{
"autoload": {
"psr-4": {
"Acme\Utils\": "src/"
}
}
}
- 主项目的
vendor/autoload.php会自动合并 path 包的 autoload 规则，无需额外操作 - 修改了目标库的
autoload后，需运行composer dump-autoload（或composer install --no-cache）才能生效 - 如果目标库用的是
files类型 autoload，确保列出的 PHP 文件存在且可读，否则 Composer 不提示，但函数不会被加载
path 仓库与 symlink 的区别和适用场景
有人会用 ln -s 把本地包软链进 vendor/，看似更轻量。但 path 仓库的优势在于：它走完整 Composer 流程（版本解析、依赖检查、autoload 注册），而 symlink 是绕过 Composer 的“手动干预”。
- path 适合多包协同开发（比如 A 依赖 B，B 又依赖 C，全部本地开发），Composer 能自动处理嵌套依赖
- symlink 适合单点快速测试，但一旦涉及版本约束或 autoload 冲突，容易出问题且难以调试
- path 仓库中修改目标库代码后，不需要重装，
composer dump-autoload即可刷新类映射；symlink 修改后也要刷 autoload，但依赖关系已脱离 Composer 管理 - 上线前必须把
path仓库换成真正的 Git 仓库地址，否则部署机找不到路径
真正麻烦的不是配置，而是忘记清理 path 仓库上线配置，或者在 CI 环境里误用了本地路径。
