composer.json字段详细说明_掌握composer配置核心参数【参考】

Composer包名必须为小写、短横线分隔的两段式vendor/name格式，如monolog/monolog；autoload中classmap优先级高于PSR-4；require-dev依赖可能引发CI环境版本冲突；config.platform仅伪报PHP/扩展版本，不影响真实环境。

name 字段必须符合 vendor/name 格式，否则 install 会失败

Composer 用 name 唯一标识一个包，不是随便起个名字就行。它必须是两段式、小写字母+短横线+数字的组合，中间用斜杠分隔，比如 monolog/monolog 或 myorg/my-package。如果写成 MyPackage、my_package、myorgmypackage，composer install 会直接报错：Invalid package name "xxx": package names must be lowercase and consist of words separated by dashes.

• vendor 名称建议用组织名或 GitHub 用户名，不能带下划线或大写字母
• package 名称不能以数字开头，也不能包含点号（.）或反斜杠（）
• 本地开发时若只是临时测试，也得先按规则填上，否则连 composer validate 都过不去

autoload 的 psr-4 和 classmap 混用时，classmap 优先级更高

PSR-4 是主流自动加载方式，但遇到无法用命名空间映射覆盖的场景（比如函数文件、全局常量、旧版类名不规范），就得靠 classmap。注意：两者共存时，Composer 生成的 autoload_classmap.php 会把 classmap 条目全塞进去，且在自动加载逻辑中优先匹配——哪怕同名类同时存在于 PSR-4 路径和 classmap 文件里，也会加载 classmap 指向的那个。

• psr-4 映射必须以 \ 结尾，例如 "App\": "src/"，漏掉反斜杠会导致命名空间解析失败
• classmap 可以指向目录或具体文件，但扫描后不会感知文件变更，需手动运行 composer dump-autoload
• 测试 autoload 是否生效，别只看 composer install 成功与否，要用 composer dump-autoload -o 后实际 new 一个类验证

require 和 require-dev 的依赖冲突常在 CI 环境暴露

require 里的包会在所有环境安装，require-dev 只在本地或 CI 的 --no-dev 未启用时才装。问题在于：如果 dev 包（如 phpunit/phpunit）间接拉入了一个和 require 中同名但版本不兼容的包（比如不同主版本的 symfony/console），composer update 可能静默降级或忽略，而 CI 执行 composer install --no-dev 时却因锁文件残留 dev 依赖的版本约束而失败。

Vondy

下一代AI应用平台，汇集了一流的工具/应用程序

下载

• 检查冲突最直接的方式是运行 composer why-not vendor/package:version
• CI 中务必用 composer install --no-dev --prefer-dist，避免本地 vendor 状态污染判断
• 不要在 require-dev 里写可能影响运行时行为的包（如 mockery/mockery 一般没问题，但 laravel/framework 就危险）

config.platform 用来锁定扩展和 PHP 版本，但只影响当前项目依赖解析

当你在服务器上没装 ext-redis，但又不想让 Composer 因为缺少扩展就跳过某些包（比如 predis/predis 替代方案），可以用 config.platform “假装”这些扩展已存在。它只在当前项目 composer install/update 时起作用，不改变真实运行环境，也不会传递给子依赖的子依赖。

• 写法是："config": { "platform": { "php": "8.1.0", "ext-redis": "5.3.7" } }
• PHP 版本填太低（如 "php": "7.4"）可能导致高版本语法包被错误排除；填太高则可能漏掉兼容性提示
• 这个字段对 composer show --platform 可见，但 php -m 或 extension_loaded() 仍反映真实状态——别把它当扩展安装替代方案