config.platform 是唯一靠谱的项目级 PHP 版本模拟方式，需写在 composer.json 的 "config": { "platform": { "php": "8.1.25", "ext-mbstring": "*", ... } } 中，仅影响依赖解析，不改变运行时环境。
直接说结论：用 config.platform 是唯一靠谱的、项目级可控的 PHP 版本“模拟”方式，不是改本地环境，而是让 Composer 解析依赖时按目标环境来算——写错位置、混用全局配置、漏配扩展，都会导致 install 失败或线上崩溃。
platform 必须写在项目 composer.json 的 config 里
很多人把 platform 写成独立文件（比如 platform.php），或者塞进全局配置（composer config -g platform.php 8.1），结果团队协作时有人生效、有人不生效。原因很简单：config.platform 只在项目根目录的 composer.json 中定义才稳定、可提交、CI 友好。
- 正确位置：
composer.json同级于require和autoload，嵌套在"config": { "platform": { ... } }里 - 错误做法：写成
config.platform.php字段（不存在）、或往~/.composer/config.json里硬塞（污染全局） - 验证是否生效：运行
composer config --list | grep platform，看到输出带(local)标记才算对
只设 php 版本不够，扩展也得手动列全
设了 "php": "8.1.25"，不代表 ext-sodium、ext-mbstring 就自动“存在”。Composer 不读你本地 php.ini，它只认你明确写进 platform 的项。一旦某个包 require "ext-sodium": "*"，而你没声明，install 就会报错。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须补全常见扩展：
"ext-sodium": "*"、"ext-mbstring": "*"、"ext-openssl": "*"、"ext-json": "*" - 扩展名严格是
ext-xxx，不是php-xxx或xxx - 版本号填
*可行，但建议填具体值（如"8.1.25"），避免某些包校验逻辑误判
--ignore-platform-reqs 是临时止痛药，不是解药
遇到 “Your requirements could not be resolved” 就加 --ignore-platform-reqs？这等于让 Composer 盲装——可能装上 PHP 8.2 才有的函数调用，部署到 PHP 8.1 服务器直接 Fatal error: Uncaught Error: Call to undefined function。
- 仅限调试：确认问题是否真出在 platform 配置上，用完立刻删掉
- CI/CD 构建绝对禁用：它绕过所有平台约束，失去提前发现兼容性问题的意义
- 真正该做的是：对照生产环境
php -v和php -m输出，把config.platform补完整
最容易被忽略的一点：platform 不影响运行时行为，只影响 install/update 阶段的依赖解析。哪怕你设成 "php": "7.4.0"，本地 PHP 8.3 依然能跑起来——但只要某行代码用了 match 表达式，PHP 7.4 环境就必然崩。所以 platform 的价值，是让错误暴露在开发阶段，而不是上线那一刻。
