Composer 不支持在 composer.json 中真正嵌入 package 仓库，仅能通过 repositories 声明外部源或用 path 类型本地包模拟；package 类型不支持索引、版本解析与依赖推导，仅适用于离线/临时场景，且必须显式配置 dist/source 和 autoload 才可生效。
Composer 不支持直接在 composer.json 里“嵌入”一个完整 package 类型仓库——你只能通过 repositories 声明外部源，或用 path 类型本地包模拟内联，但本质仍是引用，不是真正嵌入。
为什么不能真正在 composer.json 里定义一个 package 仓库？
Composer 的设计里，repositories 是用来告诉它“去哪找包”，不是“在这里定义包”。所谓“package 类型仓库”，只是手动声明某个具体包的元信息（名字、版本、dist/source 地址），它不提供索引、不支持版本约束解析、不参与依赖自动推导——只适用于极少数离线/临时场景。
常见错误现象：composer install 报错 Could not find package xxx at version yyy，或者安装后 vendor/ 里没文件，因为 Composer 没法从这种静态声明中拉取实际代码。
- 它不下载代码，除非你显式写
dist或source字段并指向有效地址 - 它不校验
autoload、require等字段是否合法，出错要等运行时才发现 - 多个
package条目之间无依赖解析能力，得自己保证顺序和兼容性
repositories.type = "package" 怎么写才不白配？
只在两种情况值得用：一是测试一个还没发到 Packagist 的私有包；二是临时替换某包的特定提交（比如等 PR 合并期间）。必须补全 dist 或 source，否则就是个空壳。
实操建议：
- 优先用
"type": "path"+ 本地目录，开发调试更可靠（"url": "../my-private-package"） - 若必须用
package，dist.url必须是可直连的 zip/tar 包地址，且dist.reference要匹配归档内顶层目录结构 - 别省略
autoload字段，否则即使装进vendor，composer dump-autoload也扫不到类 - 版本号写死，如
"version": "dev-main"，别写"dev-main as 1.0.0"——package类型不支持 alias
示例（最小可用）：
{
"repositories": [
{
"type": "package",
"package": {
"name": "acme/utils",
"version": "dev-main",
"dist": {
"url": "https://example.com/acme-utils.zip",
"type": "zip"
},
"autoload": {
"psr-4": { "Acme\Utils\": "src/" }
}
}
}
],
"require": {
"acme/utils": "dev-main"
}
}
path 类型仓库才是“伪内联”的实际解法
它让 Composer 把本地目录当做一个可安装的包来处理，支持完整字段（autoload、require、conflict），且会实时响应代码变更——这才是开发期最接近“内联”的方式。
使用场景：微服务拆分初期共用组件、私有 SDK 迭代、不想发包又需被其他项目 require。
-
path值必须是相对路径（相对于composer.json所在位置），不能用~/或绝对路径 - 目标目录下必须有合法
composer.json，否则报Package acme/foo at version dev-main has a PHP requirement incompatible with your PHP version这类误导错误 - 启用
"options": {"symlink": true}可以软链而非复制，但 Windows 下可能失败 - CI 环境默认禁用
path，需加--no-plugins或改用dist模式发布
真正的复杂点在于：你以为在“内联”，其实 Composer 仍在走标准加载流程——vendor/autoload.php 会按 PSR-4 映射加载，但不会感知你本地改了什么，除非你执行 composer dump-autoload。很多人卡在这一步，以为改了代码就该立刻生效。
