必须在composer.json的require段写死php版本约束（如"php": ">=8.1.0"），否则不同php版本环境会导致composer install失败；config.platform.php仅适用于ci等特定场景，不可提交至共享仓库；执行前需确认php命令与composer实际调用路径一致。
composer.json里必须写死php约束，不能靠口头约定
团队里有人php -v是8.2、有人是7.4，composer install在A机器成功、B机器报错，根本原因就是composer.json的require段没声明"php": "^8.1"。Composer默认按“本地能装啥就装啥”，不校验统一性。一旦提交了由PHP 8.2生成的composer.lock，7.4环境就卡死。
-
require里的php是硬性校验入口，必须写，且要覆盖团队最低可接受版本（比如"^8.1"） -
config.platform.php只是辅助模拟，不能替代require里的真实约束 - 写了
"php": ">=8.1.0"比"^8.1"更明确，避免语义化版本歧义 - 别把
config.platform.php提交到共享仓库——它只该用于CI或特定构建场景，不是开发环境配置
执行composer install前，先确认php命令指向哪个二进制
你终端敲php -v看到8.2，但composer install仍报“requires php ^8.1 but your PHP version (7.4.33)”，说明Composer实际调用的不是你期望的PHP。常见于PATH顺序错乱、alias劫持、宝塔等面板wrapper脚本。
- 运行
which php和composer diagnose | grep "PHP binary"，两行路径必须一致 - Linux/macOS：直接用完整路径执行，例如
/usr/bin/php8.2 composer install - Windows：用
"C:\php\php82\php.exe" composer install，避免系统默认php.exe干扰 - CI脚本中务必前置
php -v和which php打日志，否则排查成本翻倍
config.platform.php只在极少数场景下有效，滥用等于埋雷
config.platform.php会让Composer在解析依赖时“假装”当前是某个PHP版本，但它不改变运行时行为。本地是7.4却设成"8.2"，composer install能过，一跑match或readonly就Fatal error。
- 适用场景仅两种：CI流水线明确目标环境；开发机PHP低但需为高版本生产环境打包vendor
- 设置后必须立刻执行
composer update --lock，否则composer.lock仍记录旧平台选包结果 - 禁用场景：本地开发时设
platform.php却不验证语法兼容性；把它提交到团队仓库让所有人继承 - 查当前Composer“认为”的PHP版本：
composer show --platform，不是php -v
别用--ignore-platform-reqs当解药，它只是延迟报错
--ignore-platform-reqs会跳过所有平台检查（PHP版本、扩展、ICU），看似解决安装问题，实则把ParseError: unexpected token "match"留到运行时。这种错误更难定位，尤其在CI或上线后爆发。
- 临时调试可用
--ignore-platform-req=php（只跳过PHP版本，保留扩展校验） - 绝对不要在CI流程或git hook里固化
--ignore-platform-reqs - 如果真要降级适配，优先改
composer.json里的具体包版本（如"symfony/console": "^5.4"），而不是绕过校验 - 运行
composer why-not vendor/package:version比盲目删composer.lock更能准确定位冲突源头
require.php、显式调用目标PHP二进制、慎用config.platform.php——这三件事做扎实了，composer install才不会变成每日开工的第一道关卡。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
