管用，但仅在本地 composer install/update 时影响依赖解析，假装环境为指定 php 版本及扩展，确保生成兼容的 composer.lock；不校验真实环境，也不强制安装扩展。
composer.json 里的 platform 配置到底管不管用？
管用，但只在本地 composer install 和 composer update 时起作用——它不会强制服务器装指定 PHP 版本或扩展，也不会阻止你本地跑起来。它的核心作用是：让 Composer 在依赖解析阶段假装运行环境是某个版本，从而避免装入不兼容的包。比如团队要求 PHP ≥ 8.1 且必须有 ext-gd，但某成员本地是 PHP 7.4，没配 platform 就可能装进只兼容 8.1+ 的 monolog/monolog v3，结果一跑就报错。
-
platform是纯声明式约束，不校验真实环境 - 它影响的是
composer.lock生成逻辑，不是运行时行为 - 必须提交到 Git，否则新人 clone 后
composer install仍按本地环境选包
怎么写 platform 才能让团队真正对齐？
写法要覆盖 PHP 主版本、关键扩展、以及常见易忽略项。别只写 "php": "8.1"，这不够——它默认允许 8.1.99，但某些包（如 laravel/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-前缀，gd写成ext-gd，否则无效 - 版本号写
"8.1.0"比"^8.1"更可靠，避免解析歧义 - 不要写不存在的扩展（如
ext-redis），除非项目真依赖它；否则 CI 可能因本地缺扩展而失败，但错误提示会误导人以为是platform配置问题
CI/CD 里光靠 platform 为什么还会出问题？
因为 platform 不检查真实扩展是否加载。CI 环境 PHP 版本对了，但没装 ext-gd，代码运行时仍会崩在 gd_info() 调用上。这时候 platform 已经完成了它的使命（锁定了兼容包），但环境本身不合格。
- GitHub Actions / GitLab CI 中，必须显式安装扩展，例如 Ubuntu 上加
sudo apt-get install php8.1-gd - Docker 构建时，不能只改
FROM php:8.1-cli，还得RUN docker-php-ext-install gd - 本地开发用 Valet / XAMPP / Docker Desktop，需确认扩展确实在
php -m输出里，而不仅是php.ini里有extension=gd
团队协作中最容易被忽略的一点
platform 配置只影响当前项目的 composer install，不传递给子依赖或全局工具。比如你的项目依赖 phpunit/phpunit，而 PHPUnit 自身的 composer.json 也有 platform，那它不会被你的配置覆盖。这意味着：不同项目之间无法靠一个统一配置“传染”约束，每个 composer.json 都得单独维护。
立即学习“PHP免费学习笔记（深入）”；
- 如果用 monorepo，可在根目录设
platform，但各子包仍需各自声明（Composer 不跨路径继承） -
composer update时若没加--with-all-dependencies，子依赖的platform可能被忽略，导致 lock 文件实际装入不一致版本 - 最保险的做法：把
platform配置项和对应 PHP/扩展版本要求写进 README，并在 PR 检查中加一行php -v && php -m | grep -E '^(gd|mbstring|openssl)$'
