config.platform必须写在composer.json的"config": {"platform": {...}}内，不可置于根级或require中；写错路径则完全无效，仅影响install/update依赖解析，不改变运行时环境。
config.platform 写在哪？路径错就全白配
必须写在 composer.json 的 config.platform 下，不是根级 platform，也不是 require 里。写错位置等于没写——Composer 完全忽略。
- ✅ 正确：
"config": {"platform": {"php": "8.1.25", "ext-zip": "true"}} - ❌ 错误：
"platform": {"php": "8.1.25"}（顶层字段，无效） - ❌ 错误：
"require": {"ext-zip": "*"}（触发 platform-check 失败，非运行时判断）
验证是否生效：执行 composer show --platform，输出应包含你设的 PHP 版本和扩展；若为空或显示本地真实版本，说明配置未加载。
为什么 config.platform 能防 CI 构建失败
CI 环境（如 GitHub Actions、GitLab Runner）常使用最小化 PHP 镜像（如 php:8.1-cli-alpine），缺扩展、版本旧、甚至没 ext-gd。不加 config.platform，Composer 会按本地开发机的 PHP 版本选包，导致装出依赖 PHP 8.2+ 或 ext-mbstring 的包，上线后直接 Fatal error。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 设
"php": "8.1.25"后，Composer 解析依赖时只考虑兼容该版本的包版本，哪怕你本地是 8.2 - 设
"ext-zip": "true"不代表强制安装扩展，而是告诉 Composer：“当成已存在”，跳过检查，避免因 CI 镜像无 zip 扩展而中断 - 注意：
config.platform不影响运行时行为，只约束依赖解析阶段——它解决的是“装什么”，不是“能不能跑”
config.platform 和 --ignore-platform-reqs 的关系
二者目标相似但机制相反：config.platform 是声明“我假装有这些环境”，--ignore-platform-reqs 是命令行开关“我不管当前有没有”。生产构建中，优先用前者，后者仅用于 builder 阶段临时绕过。
- ✅ 推荐组合：Dockerfile 中多阶段构建，builder 阶段用
--ignore-platform-reqs快速装完依赖；最终镜像基于config.platform生成的composer.lock，确保一致性 - ❌ 危险用法：在生产容器启动脚本里加
--ignore-platform-reqs，会掩盖真实缺失扩展，导致运行时报错而非构建时报错 - ⚠️ 版本冲突：若
config.platform.php设为"8.1.0"，但composer.lock里记录的包要求^8.2，Composer 仍会报错——lock 文件优先级高于 platform，必须先composer update --with-all-dependencies重新生成 lock
跨 Windows/macOS/Linux 时 platform 配置的陷阱
Windows 上 ext-pcntl 永远不存在，macOS 默认没 ext-inotify，Linux 可能缺 ext-sodium。硬写进 require 会导致其他系统 composer install 直接失败。但 config.platform 不能模拟 OS 差异——它只支持 php 和扩展名，不支持 os 或 PHP_OS_FAMILY。
- 唯一解法：把 OS 专属扩展（如
ext-inotify）彻底移出require和require-dev，改用代码里extension_loaded('inotify') && PHP_OS_FAMILY === 'Linux'判断 -
config.platform只能帮你“稳住 PHP 版本和常见扩展”，OS 层适配必须由运行时逻辑兜底 - CI 中若需测试多 OS 行为，应在不同 runner 上分别跑
composer install+ 单元测试，而不是靠 platform 配置“假装”存在
真正容易被忽略的点是：platform 配置不解决扩展功能差异，只解决依赖解析阶段的兼容性声明。哪怕你写了 "ext-curl": "true"，如果实际环境 curl 版本太旧或没启用 SSL 支持，运行时照样出错。
