不能将PHP扩展（如ext-curl、ext-redis）写入require-dev，因Composer仅校验环境是否已启用该扩展，不负责安装；扩展必须由系统层（如Dockerfile中docker-php-ext-install）安装，require-dev对此无控制力。
require-dev 里放扩展依赖？别这么干
PHP 扩展（如 ext-curl、ext-redis）不是普通 Composer 包，不能写进 require-dev 或 require 字段。Composer 不会帮你安装或启用它们——它只校验当前 PHP 环境是否已加载该扩展。把 "ext-redis": "*" 写进 require-dev，只是告诉 Composer「我开发时需要这个扩展存在」，不解决任何安装问题。
常见错误现象：composer install 在 CI 上失败，报错 The requested PHP extension ext-redis is missing，但本地好好的——说明 CI 容器没装扩展，而你误以为 Composer 能“补上”。
- 扩展必须由系统/容器层安装：Dockerfile 里用
docker-php-ext-install redis，或宿主机执行pecl install redis -
composer.json中声明扩展，仅用于约束和提前报错，不是安装手段 - 扩展版本号要写死（如
"ext-json": "1.5.0"），不能用^1.5—— Composer 不支持扩展的语义化版本解析
如何让不同环境容忍不同扩展？
生产环境可能禁用 ext-xdebug，CI 需要 ext-opcache，但本地开发又依赖 ext-mbstring。你不该靠改 composer.json 来切换，而应利用 config.platform 欺骗 Composer，让它忽略当前缺失的扩展。
例如，在 CI 脚本中临时跳过对 ext-xdebug 的检查：
COMPOSER_DISABLE_EXTENSIONS=1 composer install
或者在 composer.json 中硬编码平台配置（适用于固定环境）：
"config": {
"platform": {
"ext-xdebug": "0",
"ext-apcu": "5.1.20"
}
}
注意：config.platform 是静态声明，不是运行时检测——它只影响 Composer 解析依赖时的判断，不改变实际 PHP 环境。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
COMPOSER_DISABLE_EXTENSIONS=1是最轻量的 CI 适配方式，适合临时绕过非关键扩展 -
config.platform更适合长期稳定的部署目标（如线上 PHP 版本+扩展集） - 两者都**不会**导致扩展被自动安装，只是让 Composer 停止校验
为什么不能用 require-dev 区分 staging/prod 的扩展？
因为 require-dev 控制的是「包是否被下载安装」，而扩展根本不是包。你无法通过 --no-dev 让 ext-pcntl 在生产环境“消失”，它要么已加载，要么没加载——Composer 对它没有控制权。
真实场景中容易踩的坑：
- 把
"ext-gd": "*"放进require-dev，结果生产环境因缺 GD 报错，却误以为是--no-dev没生效 - CI 流水线跑测试时漏装
ext-sqlite3，但composer install --no-dev成功了，掩盖了运行时失败 - 用
composer show --platform查到的扩展列表，是 Composer “假装看到”的，不是php -m真实加载的
扩展依赖管理的真正边界在哪？
Composer 只做三件事：声明扩展需求、校验当前环境、在不满足时提前报错。它不负责安装、启用、配置或卸载扩展。所有扩展相关的操作，必须下沉到基础设施层。
这意味着：
- Dockerfile 必须显式安装所需扩展，不能依赖 Composer
- 部署文档或 README 必须明确列出
ext-*依赖项，而非藏在require-dev里 - CI 脚本应在
composer install前，先运行php -m | grep -E '^(curl|redis)$'做环境预检 - 如果某个扩展只在 dev 环境需要（如
ext-xdebug），就别写进composer.json—— 它不影响代码运行，只影响调试体验
最常被忽略的一点：扩展缺失的错误发生在 composer install 阶段，但根源永远不在 Composer 本身。盯着 composer.json 改来改去，不如检查 php.ini 和容器构建日志。
