Composer如何处理平台虚拟包_Composer platform配置说明【核心】-composer-PHP中文网

config.platform是唯一稳定控制依赖解析目标环境的机制，必须严格写在composer.json的config对象内，如"config": {"platform": {"php": "8.1.25", "ext-mbstring": "*"}}，仅影响install/update阶段依赖选择，不改变运行时行为。

composer如何处理平台虚拟包_composer platform配置说明【核心】

config.platform 是唯一能稳定控制依赖解析目标环境的机制，其他方式要么无效、要么污染全局、要么绕过约束。

platform 必须写在 composer.json 的 config 里

很多人把 platform 写成独立文件、塞进全局配置、或误放成根级字段（如直接写 "platform": { "php": "8.1" }），结果 CI 构建失败、本地 install 成功但线上报错。原因很直接：config.platform 只在项目根目录的 composer.json 中、嵌套于 "config": { "platform": { ... } } 下才生效。

验证是否生效：运行 composer config --list | grep platform，看到输出带 (local) 标记才算对。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

错误位置示例："platform" 直接写在 composer.json 根对象第一层、或写在 ~/.composer/config.json 里
正确结构必须是："config": { "platform": { "php": "8.1.25", "ext-mbstring": "*" } }
它不可被 require 或 autoload 影响，只参与 install/update 阶段的依赖图计算

只设 php 版本不够，扩展必须手动列全

设了 "php": "8.1.25"，不代表 ext-sodium、ext-openssl 就自动“存在”。Composer 不读你本地 php.ini，它只认你明确写进 config.platform 的项。一旦某个包 require "ext-sodium": "*"，而你没声明，composer install 就会中断。

常见必须补全的扩展："ext-sodium": "*"、"ext-mbstring": "*"、"ext-openssl": "*"、"ext-json": "*"、"ext-pdo": "*"
扩展名严格为 ext-xxx，不是 php-xxx 或 xxx；大小写敏感：ext-curl ✅，ext-CURL ❌
版本号填 * 多数够用，但某些包（如 symfony/cache）会检查扩展版本 ≥ 某值，这时建议写死，如 "ext-redis": "5.3.7"

platform 不影响运行时，只影响 install/update 阶段

哪怕你设成 "php": "7.4.0"，本地 PHP 8.3 依然能跑起来——但只要某行代码用了 match 表达式，PHP 7.4 环境就必然崩。这是最容易被忽略的一点：platform 是编译期约束，不是运行时模拟。

它不安装任何扩展，也不改 phpversion() 返回值
composer install 时，它只决定“哪些包能进依赖树”，不决定“代码能不能执行”
如果 composer.lock 已存在，install 默认复用其中版本，不会重新按 platform 解析 —— 需加 --with-all-dependencies 或删 lock 文件重装
--ignore-platform-reqs 会彻底跳过 platform 检查，CI/CD 中禁用；仅限临时排查是否真由 platform 引发问题

扩展缺失时，polyfill 不一定能替代

有些包通过 provide 声明虚拟扩展（如 symfony/polyfill-mbstring 提供 ext-mbstring），此时 config.platform 中的 "ext-mbstring": "*" 可能被绕过。但真实环境没扩展时，polyfill 往往不能 100% 覆盖原生行为（比如部分 mbstring 函数的编码检测逻辑）。

如果你的应用明确依赖原生扩展的特定行为（如 mb_ereg_replace 的 PCRE 兼容性），就不能只靠 polyfill + platform 混搭
判断依据是生产环境 php -m 输出 —— platform 必须和这个输出严格对齐，而不是“差不多有就行”
跨环境部署（如同时跑在阿里云函数和老 CentOS）时，platform 应取所有目标环境的最小交集，否则 install 阶段就会失败