管用，但仅在本地 composer install/update 时影响依赖解析，假装环境为指定 PHP 版本及扩展，确保生成兼容的 composer.lock；不校验真实环境，也不强制安装扩展。
composer
.json 里的
配置到底管不管用？
管用，但只在本地
和
时起作用——它不会强制服务器装指定 PHP 版本或扩展，也不会阻止你本地跑起来。它的核心作用是：
让 Composer 在依赖解析阶段假装运行环境是某个版本，从而避免装入不兼容的包
。比如团队要求 PHP ≥ 8.1 且必须有
，但某成员本地是 PHP 7.4，没配
就可能装进只兼容 8.1+ 的
v3，结果一跑就报错。
是纯声明式约束，不校验真实环境
它影响的是
生成逻辑，不是运行时行为
必须提交到 Git，否则新人 clone 后
仍按本地环境选包
怎么写
才能让团队真正对齐？
写法要覆盖 PHP 主版本、关键扩展、以及常见易忽略项。别只写
，这不够——它默认允许
，但某些包（如
）会要求
或更严。推荐显式锁定最小兼容边界：
扩展名必须用
前缀，
写成
，否则无效
版本号写
比
更可靠，避免解析歧义
不要写不存在的扩展（如
），除非项目真依赖它；否则 CI 可能因本地缺扩展而失败，但错误提示会误导人以为是
配置问题
CI/CD 里光靠
为什么还会出问题？
因为
不检查真实扩展是否加载。CI 环境 PHP 版本对了，但没装
，代码运行时仍会崩在
调用上。这时候
已经完成了它的使命（锁定了兼容包），但环境本身不合格。
PHP 8.5.5
PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载
GitHub Actions / GitLab CI 中，必须显式安装扩展，例如 Ubuntu 上加
Docker 构建时，不能只改
，还得
本地开发用 Valet / XAMPP / Docker Desktop，需确认扩展确实在
输出里，而不仅是
里有
团队协作中最容易被忽略的一点
配置只影响当前项目的
，不传递给子依赖或全局工具。比如你的项目依赖
，而 PHPUnit 自身的
也有
，那它不会被你的配置覆盖。这意味着：
不同项目之间无法靠一个统一配置“传染”约束，每个都得单独维护
。
立即学习
“
PHP免费学习笔记（深入）
”；
如果用 monorepo，可在根目录设
，但各子包仍需各自声明（Composer 不跨路径继承）
时若没加
，子依赖的
可能被忽略，导致 lock 文件实际装入不一致版本
最保险的做法：把
配置项和对应 PHP/扩展版本要求写进 README，并在 PR 检查中加一行
platformcomposer installcomposer updateext-gdplatformmonolog/monologplatformcomposer.lockcomposer installplatform"php": "8.1"8.1.99laravel/framework^8.1.0
"config": {
"platform": {
"php": "8.1.0",
"ext-gd": "8.1.0",
"ext-mbstring": "8.1.0",
"ext-openssl": "8.1.0",
"ext-pdo": "8.1.0",
"ext-pdo_mysql": "8.1.0"
}
}
ext-gdext-gd"8.1.0""^8.1"ext-redisplatformplatformplatformext-gdgd_info()platformsudo apt-get install php8.1-gdFROM php:8.1-cliRUN docker-php-ext-install gdphp -mphp.iniextension=gdplatformcomposer installphpunit/phpunitcomposer.jsonplatformcomposer.jsonplatformcomposer update--with-all-dependenciesplatformplatformphp -v && php -m | grep -E '^(gd|mbstring|openssl)$'