根本原因是composer install只按composer.lock还原依赖，而该文件通常由高版本PHP生成，其包版本可能含PHP 8.1+语法或扩展依赖，导致在PHP 7.4等旧环境中运行时报ParseError；platform配置需精确指定目标PHP小版本（如"7.4.33"）及所有扩展，并配合composer update --with-all-dependencies重算依赖图才能生效。
为什么composer install在旧PHP上会失败，即使composer.json写了约束
根本原因不是约束没写对，而是composer install完全不看composer.json里的PHP版本声明或包版本范围——它只照composer.lock装。而这个lock文件，极大概率是用新PHP（比如8.2）跑composer update生成的，里面记录的包版本可能依赖PHP 8.1+的语法或扩展（如mbstring函数签名变更、enum类型等），直接扔到PHP 7.4环境就会报ParseError或Class not found。
常见错误现象：
-
composer install成功，但php index.php启动就Fatal error -
composer show vendor/package显示已安装，但class_exists('SomeClass')返回false - CI里PHP 7.4构建失败，本地PHP 8.2却一切正常
platform配置必须写死PHP和扩展版本
仅靠"php": ">=7.4.0"这种软约束没用，Composer默认忽略它去选最新包。真正起作用的是config.platform——它会欺骗Composer“当前环境只有这些PHP能力和扩展”，从而在update阶段就排除掉不兼容的包版本。
正确写法（放在composer.json的config节）：
立即学习“PHP免费学习笔记（深入）”；
"config": {
"platform": {
"php": "7.4.33",
"ext-mbstring": "7.4.33",
"ext-openssl": "7.4.33",
"ext-json": "7.4.33"
}
}
关键点：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
php值必须是目标环境**实际运行的精确小版本号**，比如7.4.33，不是7.4或^7.4 - 所有项目代码中用到的扩展（
mbstring、gd、pdo_mysql等）都得列出来，版本号统一填7.4.33（只要存在即可，Composer不校验扩展真实版本） - 改完后必须跑
composer update --with-all-dependencies重算整个依赖图，否则composer.lock仍含高版本包
包版本约束要配合platform一起生效
单独写"monolog/monolog": "^2.0"在PHP 7.4下可能装到2.10.0（它要求PHP 8.0+），但加上platform后，Composer会自动降级到2.9.2（最后一个支持7.4的版本）。这不是运气，是约束协同的结果。
实操建议：
- 核心包优先用精确版本：
"guzzlehttp/guzzle": "7.4.5"（查Packagist确认该版本最低PHP要求） - 非核心包用
~锁次版本："symfony/console": "~5.4"→ 等价于>=5.4.0 ，且<code>platform会确保选其中PHP 7.4兼容的最高版 - 绝对不要用
^配老PHP："^3.0"在PHP 7.4下可能无可用版本，导致update失败 - 验证是否真兼容：在PHP 7.4环境下执行
composer update --dry-run，看输出里有没有skipped或not compatible提示
composer.lock必须按目标PHP环境生成并提交
团队里有人用PHP 8.2跑composer update，然后提交lock文件，等于给所有人埋雷。lock文件不是“通用快照”，它是“特定平台快照”。
正确流程：
- CI脚本第一行必须切到目标PHP版本：
phpenv local 7.4.33（或Docker指定php:7.4-apache） - 运行
composer update --with-all-dependencies，而非install - 把生成的
composer.lock连同composer.json一起提交 - 本地开发也必须用相同PHP版本跑
update，不能“先在8.2上装好再复制vendor”
最容易被忽略的一点：即使platform写对了，如果composer.lock是别人用高版本PHP生成的，你本地install时依然会装错——lock文件本身不包含PHP平台信息，它只记录包版本，而那个版本早已被高版本环境选中，不再受你本地platform约束。
