type字段决定包的安装方式和加载行为，必须填library、project、metapackage或composer-plugin等composer识别的值，填错会导致自动加载失败、插件不生效或packagist提交失败。
composer.json 里的 type 字段到底填什么
它不是随便写的标签，而是 Composer 用来决定“怎么安装这个包”的关键开关。填错会导致包被装进 vendor/ 错误位置，甚至根本不会被自动加载。
-
library（默认值）：普通 PHP 类库，走 PSR-4 自动加载，最常见 -
project：表示这是一个完整可运行项目（比如 Laravel 应用），create-project时会用到，require它没意义 -
metapackage：纯依赖聚合包，自身没代码，只靠require拉其他包，不带autoload -
composer-plugin：必须实现Composer\Plugin\PluginInterface，会被 Composer 运行时加载并执行
别写 package、module、extension 这类自定义值——Composer 不认识，直接当 library 处理，但后续工具链（如 Packagist）可能拒收或降权。
type 设错的典型报错和表现
你不会看到 “type 错误” 这种直白提示，而是遇到下游症状：
- 设成
project却在另一个项目里composer require vendor/name→ 包进了vendor/，但 PSR-4 加载失败，Class not found - 想写个插件却用了
library→composer install后插件类从不被触发，composer global也无效 - 用
metapackage却漏了require块 → Packagist 提交失败，提示 “no dependencies defined”
检查方式很简单：composer show vendor/name 输出里看 type 行，再对照你的实际用途。
packagist.org 对 type 的硬性要求
Packagist 不是来者不拒的仓库，它对某些 type 有明确校验逻辑：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer-plugin必须提供extra.composer-plugin-class配置项，指向具体类名 -
metapackage必须至少有一个require条目，且不能有autoload -
project类型包，Packagist 会隐藏其“作为依赖被 require”的能力，只支持create-project
提交失败时错误信息通常是：The package type "xxx" is not supported 或 Missing required key "extra.composer-plugin-class" —— 别改错地方，先核对 type 和配套字段是否成套出现。
type 和 autoload、installer 的联动关系
type 本身不干活，但它会触发 Composer 内部不同的 installer（安装器）。比如：
-
library→LibraryInstaller→ 尊重autoload，复制文件到vendor/ -
composer-plugin→PluginInstaller→ 强制检查类是否存在、是否实现接口，不走 PSR-4 加载 - 自定义
type（如cakephp-plugin）→ 需提前注册对应 installer，否则退化为library
所以如果你在 composer.json 里写了 "type": "laravel-package" 却没配 Laravel 的 installer（比如 laravel/framework 自带的），那它只是个普通 library，别指望 ServiceProvider 自动发现。
真正难的不是填哪个值，而是想清楚：这个包在别人项目里，到底该被“加载”还是“执行”还是“展开”——type 是你向整个生态声明意图的唯一字段，填之前得确认自己能履约。
