直接读 composer.json 文件本身是最可靠的方式，PHP 运行时无法通过 Composer 提供的 API 获取字段值——它压根没暴露这个能力。
require 和 require-dev 不是“开发用/生产用”标签
这两个字段决定包是否被安装，但不控制运行时行为。装进 require-dev 的包，在执行 composer install --no-dev 时根本不会出现在 vendor/ 里，所以别指望它们在生产环境起作用。
-
require放运行时真正依赖的包，比如"guzzlehttp/guzzle": "^7.0"；漏掉会导致Class not found或Call to undefined function -
require-dev放测试、格式化、生成代码等工具，比如"phpunit/phpunit": "^9.5"；CI 环境若用了--no-dev，这些包就完全不可见 - 某些包（如
symfony/console）可能同时用于开发和运行时，得看你的代码是否在生产环境调用它，而不是看包名
autoload 配置错一个字符就 Class not found
PSR-4 映射不是“大概对就行”，命名空间、路径、反斜杠、大小写必须严丝合缝。Composer 不会报错，只会静默跳过加载。
-
"psr-4": {"App\": "src/"}要求：类文件路径为src/Http/Controller.php，且该文件首行必须是namespace App\Http;（注意末尾有反斜杠） - 漏掉
\、写成app\或App/，都会导致自动加载失败 - 改完
autoload后必须手动执行composer dump-autoload，否则缓存仍是旧的 -
classmap是兜底方案，适合无命名空间的老代码，但增删文件后也得重跑dump-autoload
platform 字段必须和 require 同级，config.platform 无效
想锁定 PHP 版本或扩展版本让 CI 安装一致的依赖？config.platform 是常见误写，它完全被忽略。唯一生效的是顶层 platform 字段。
- 正确写法：
"platform": {"php": "7.4.33", "ext-gd": "8.0.0"}，和require并列 - 错误写法：
"config": {"platform": {"php": "8.1.0"}}—— Composer v2+ 已彻底移除对该结构的解析 -
platform只影响依赖解析过程，不改变你本地 PHP 实际版本，也不影响运行时行为 - 验证是否生效：运行
composer show php看显示的仍是本地版本，但composer install后vendor/composer/installed.json中的包版本应匹配platform声明的环境
type 字段只是元数据，不控制安装逻辑
type 字段不会让 Composer “变成项目”或“变成库”，它只被 Packagist、插件或 CI 工具读取，用于分类或路径约定。
-
"type": "project"表示这是个可独立运行的应用（如 Laravel 模板），Packagist 不会把它当依赖推荐 -
"type": "library"（默认）表示可被其他项目require，需配好autoload -
"type": "metapackage"是空包，只声明依赖，不放源码；"type": "composer-plugin"必须实现接口，否则加载失败 - 乱填
type（如"my-app"）基本没副作用，但 Packagist 可能拒收，或下游工具无法识别用途
最常被忽略的是路径定位问题：PHP 脚本里读 composer.json 不能硬写 ./composer.json，得从 getcwd() 向上遍历找文件，还要检查 COMPOSER 环境变量是否指定了非默认配置名。
