Composer 的 platform 配置不能锁定 PHP 版本，仅在依赖解析时伪装环境版本以绕过约束检查；它不管理运行时、不干预执行、不保证兼容性，真实 PHP 版本不符仍会运行时报错。
Composer 的 platform 配置不能真正“锁定”PHP 版本，它只是在依赖解析时伪装当前运行环境的 PHP 版本，用于绕过平台约束检查——实际运行仍取决于你本地或部署环境的真实 PHP 版本。
为什么 platform 不是版本锁？
Composer 本身不管理 PHP 运行时，platform 只影响 composer install 或 update 时的依赖兼容性判断。它告诉 Composer：“假装我现在跑的是 PHP 8.1”，从而让那些声明了 "php": "^8.1" 的包能被装上，哪怕你本地是 PHP 8.2 或 7.4。
- 它不会阻止你用 PHP 8.2 执行代码，也不会降级你的 PHP
- 它不会修改
vendor/autoload.php的行为或生成的 autoloader - 如果真实 PHP 版本低于依赖要求（比如要求 8.1 但你只有 7.4），运行时仍会报错，
platform压根不干预这个阶段
platform 的正确写法和位置
必须写在 composer.json 的 config 段内，键名为 platform，值为对象，key 是扩展名或 php，value 是版本字符串：
{
"config": {
"platform": {
"php": "8.1.10",
"ext-gd": "8.1.10",
"ext-mbstring": "8.1.10"
}
}
}
-
php字段是唯一强制生效的 platform 项；其他扩展如ext-redis只有在包的require中明确写了该扩展依赖时才起作用 - 版本号写法要合法：不能写
"8.1"（会被当作^8.1.0解析，可能触发意外匹配），推荐写完整补丁版如"8.1.10"或通配符"8.1.*" - 该配置只对当前项目生效，不影响全局 Composer 行为
常见误用场景和后果
很多人加 platform 是为了在 CI 或旧服务器上“骗过”安装，但容易埋坑：
立即学习“PHP免费学习笔记（深入）”；
- CI 环境 PHP 是 8.0，却设
"php": "8.2.0"→ 安装成功，但运行时报Undefined constant FILTER_VALIDATE_FLOAT等 8.2 新特性错误 - 本地开发用 PHP 8.3，
platform锁成 8.1 →composer update可能选到不兼容 8.3 的旧版包（因为 Composer 认为你“只能用 8.1 兼容的”） - 误把
platform当作engines（Node.js 那套）→ 它不校验、不警告、不中断执行，纯属“自欺式兼容”
比 platform 更靠谱的替代方案
真要控制 PHP 版本兼容性，优先靠这些：
- 在
composer.json的require里写明"php": "^8.1"—— 这才是向所有使用者声明最低要求 - CI 脚本中显式指定 PHP 版本（如 GitHub Actions 的
php-version: '8.1'），而不是靠platform掩盖 - 用
composer show --platform查看当前 platform 设置是否生效，再结合php -v对比真实版本 - 需要多版本测试？用
docker run --rm -v $(pwd):/app -w /app php:8.1-cli composer install，比改platform更干净
真正容易被忽略的点是：一旦加了 platform，团队成员很容易默认“这个项目就跑在这个 PHP 版本上”，而不再验证真实环境——结果上线后第一秒就 Fatal error。
