关键是要分离并统一控制“Composer用哪个PHP执行”和“按哪个PHP版本选包”：一、在composer.json中设config.platform.php为具体版本（如"8.1.0"），仅影响依赖解析；二、require.php定义运行时最低要求；三、用php -v、which php和composer show --platform定位不匹配；四、确保composer.lock由目标环境PHP生成且全环境一致。
要防止本地与生产环境因 PHP 版本不一致导致部署失败或运行异常，关键不是“让 Composer 自动适配”，而是主动控制两个环节：**Composer 用哪个 PHP 执行**，以及**它按哪个 PHP 版本选包**。这两者必须明确分离、统一声明。
一、在 composer.json 中正确设置 platform.php
这是最常用也最可控的方式，尤其适合团队协作和 CI/CD 场景。它让 Composer 在解析依赖时“假装”当前是目标 PHP 版本，从而选到兼容的包版本（例如避免装入只支持 PHP 8.2 的新特性包）。
- 在
composer.json的config字段下添加platform配置（若无config则新建） -
platform.php的值必须是具体字符串，如"8.1.0"或"^8.1"；不支持~8.1写法，否则会报错 - 该配置只影响依赖解析过程（即
composer update时选什么版本），不影响实际运行——你仍需确保部署环境真有对应 PHP 版本
二、区分 require.php 和 config.platform.php 的作用
require.php 是运行时闸门，定义项目最低 PHP 要求；config.platform.php 是构建时约束，控制依赖解析逻辑。两者都要设，但目的不同。
-
"require": { "php": "^8.1" }告诉别人：“这个项目至少需要 PHP 8.1 才能跑” -
"config": { "platform": { "php": "8.1.0" } }告诉 Composer：“就算我本地是 PHP 8.2，你也按 8.1.0 的能力来挑包” - 如果只设
require.php而没设platform，CI 环境可能因 PHP 版本高而装入不兼容旧版的依赖，导致线上崩溃
三、快速定位版本不匹配问题
当 composer install 报 “PHP version does not satisfy that requirement” 时，不是 Composer 出错，而是声明与执行环境脱节。
立即学习“PHP免费学习笔记（深入）”；
- 先运行
php -v和which php，确认当前 shell 下真实的 CLI PHP 版本和路径 - 检查
composer.json中的require.php和config.platform.php，注意后者优先级更高 - 运行
composer show --platform查看 Composer “认为”的 PHP 版本，比对是否与预期一致 - 若发现
config.platform.php错误锁定为低版本，修改后必须执行composer update --lock，否则composer.lock仍记录旧平台信息
四、确保 composer.lock 在多环境中真正一致
composer.lock 是唯一可信的依赖快照。它必须在所有环境保持完全一致，否则就失去了“可重现构建”的意义。
- 生成 lock 文件时，应使用目标环境的最低 PHP 版本执行：
/usr/bin/php8.1 composer update --lock - 禁止仅靠
config.platform.php“降级”本地高版本来生成 lock——比如本地是 PHP 8.2 却设"platform": {"php": "8.1.0"}，可能导致 autoload 生成含 8.2 语法的文件，上线后直接 ParseError - 若需支持多个主版本（如 PHP 8.1 和 8.2），
require.php应写成"^8.1 || ^8.2"，并验证所有依赖（尤其是 require-dev 工具）真实兼容两者
