composer install完全忽略description、keywords、support等元信息字段，仅用于Packagist展示或搜索；type字段则直接影响安装行为：library复制到vendor/并支持require，project不被依赖且不写自身代码，metapackage仅触发依赖安装；填错type会导致autoload失效或Class not found。
composer install 不读取 description、keywords、support 等文档类字段
这些字段纯属元信息，只在 Packagist 页面展示或用于搜索，composer install 过程中完全忽略它们。填错 description 不会导致安装失败，但会误导用户——比如写成 "description": "run composer install first"，实际毫无作用，Packagist 也只截取前 120 字显示。
常见误用场景：
- 把安装步骤塞进
description，指望用户看到就执行——结果没人看见，也没人触发 - 在
support.issues填了个失效的 GitHub URL，用户点进去 404，但composer install照常跑完 -
keywords写得太宽泛（如["php", "tool"]），不影响安装，但会拉低 Packagist 搜索权重
type 字段直接影响 vendor/ 下的文件放置逻辑
type 不是标签，而是安装行为开关。它决定 Composer 是否把包复制到 vendor/，以及是否允许被其他项目 require。
关键区别：
-
"type": "library"（默认）：包内容复制进vendor/vendor/name/，可被其他项目依赖 -
"type": "project"：不被其他包require，且不会往vendor/写自身代码（只装依赖），适合 Laravel 标准版这类应用 -
"type": "metapackage"：自身无文件，只触发依赖安装，vendor/下连目录都不建
填错 type 的后果很直接：比如把一个真实库设为 project，别人 require 它时会静默跳过，autoload 失效，报 Class not found。
autoload 和 autoload-dev 在 install 阶段生成自动加载逻辑
composer install 会根据 autoload 和 autoload-dev 字段生成 vendor/autoload.php 及相关映射文件，但仅当 --no-dev 未启用时才处理 autoload-dev。
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
注意点：
-
psr-4映射路径必须以结尾，例如"App\": "src/"，漏掉反斜杠会导致命名空间解析失败 -
classmap条目优先级高于psr-4，同名类存在时一定加载classmap指向的文件 -
autoload-dev里的路径，在composer install --no-dev下不会写入最终 autoload 文件，测试类无法被自动加载
验证方式不是看 install 是否成功，而是运行 composer dump-autoload -o 后手动 new AppSomeClass 测试是否能找到。
platform 配置在 install 时强制校验 PHP 环境兼容性
config.platform 是唯一能在 composer install 阶段主动干预依赖解析的“伪装”字段。它不改变真实环境，但会让 Composer 按照你声明的 PHP 版本和扩展去匹配 composer.lock 中已锁定的包。
典型问题：
-
"platform": {"php": "8.2.10"}，但本地实际是 PHP 8.1 → 报Your requirements could not be resolved，哪怕所有包都下载下来了 -
"platform": {"ext-mbstring": "true"}，但系统没启用该扩展 →composer diagnose会标出，install也可能失败 - CI 脚本里写了
--ignore-platform-reqs→ 安装成功，但运行时因缺扩展或版本不匹配直接 fatal error
这个字段的坑在于：它只在校验阶段起作用，一旦绕过（比如加了 --ignore-platform-reqs），后续 autoload 或运行时崩溃不会提前暴露。
