type字段仅为元数据标识符，不改变composer安装行为；它被packagist、composer/installers等工具读取以分类包或决定安装路径，常见值如library（默认）、project（可运行应用）、metapackage（依赖集合）、composer-plugin（插件）。
type 字段不控制安装行为，只起标识作用；写错或漏写不会让 composer install 报错，但会让插件不加载、元包被误装、Packagist 拒收或框架安装器失效。
什么时候必须显式写 type？
只有三类情况不写会出实际问题：
-
metapackage：必须写，且不能有autoload或src/目录，否则 Packagist 拒收 -
composer-plugin：必须写，且包内类要实现Composer\Plugin\PluginInterface，还得在extra.plugin-class里指定完整命名空间 -
project：非强制，但 Laravel/Symfony 模板类项目建议写，防止别人composer require vendor/name导致嵌套结构混乱
library 和 project 怎么选？
核心看使用方式：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 能被其他项目
require的，就是library——必须配autoload（如 PSR-4），否则别人引入后类找不到 - 只打算用
composer create-project初始化的独立应用（含public/index.php、完整启动逻辑），就该是project - 误把
project设成library，它可能被当成普通依赖装进别人vendor/，引发自动加载冲突或路径错乱
wordpress-plugin 这类 type 为什么没反应？
它们本身没魔法，真正干活的是 composer/installers：
- 必须在根项目的
require中声明"composer/installers": "^2.0"（注意版本兼容性） -
type值必须严格匹配安装器注册名，比如"wordpress-plugin"，拼成"wp-plugin"就无效 - 没装
composer/installers时，type: "wordpress-plugin"和type: "library"完全等价，照样进vendor/，不会自动扔进wp-content/plugins/
type 写错的典型表现
错误往往静默发生，现象比报错更难排查：
- Packagist 发布失败，报错
"metapackage must not contain autoloading rules"——其实是写了"type": "metapackage"却忘了删autoload -
composer require vendor/plugin后插件没生效——大概率是type没设"composer-plugin"，或extra.plugin-class指向的类不在autoload范围内 -
composer create-project vendor/app初始化后，vendor/里多出一堆重复依赖——源项目type还是默认"library"，被当成普通包参与了依赖解析
最易被忽略的一点：type 不是开关，它不改自动加载、不干预安装流程、也不影响 composer install 的执行结果；它的价值全在工具链协作上——Packagist 展示、CI 脚本判断、安装器路由、插件加载时机，都靠它传递意图。写错不会让你的命令挂掉，但会让你的自动化流程在某个环节突然“失语”。
