是 Composer 自己调用 extension_loaded() 做的运行时校验，它读取 composer.json 的 require 字段（如 "ext-gd": "*"），执行 php -m 对比验证，缺失即中断安装、不写 composer.lock；该检查仅针对 CLI 环境，与 Web 配置无关。
composer install 报 ext-xxx missing 是谁在检查？
是 Composer 自己调用 extension_loaded() 做的运行时校验，不是 PHP 解释器或系统在报错。它只读 composer.json 的 require 字段，比如 "ext-gd": "*"，然后执行 php -m 对比输出列表——缺就中断，不写 composer.lock，也不下载任何包。
常见误判点：
- CLI 和 Web 使用不同
php.ini：你配了 Apache 的extension=gd.so，但php -m走的是 CLI 的配置，结果报错 -
xdebug.mode=off或zend_extension未启用：即使 .so 文件存在，php -m也看不到xdebug -
ext-redis版本号写成"^5.3.7"：这不是扩展发布版本，而是对应 PHP ABI 兼容标识，实际只校验是否存在，不校验真实版本号
如何让脚本自动检测并提示缺失的 C 扩展？
别指望 Composer 自带“智能安装”，它只报错、不修复。你需要自己补一层检测逻辑，放在 CI 或部署前的预检脚本里：
示例（bash）：
#!/bin/bash
MISSING=()
for ext in gd redis openssl sodium; do
php -r "exit(extension_loaded('$ext') ? 0 : 1);" 2>/dev/null || MISSING+=($ext)
done
if [ ${#MISSING[@]} -ne 0 ]; then
echo "Missing extensions: ${MISSING[*]}"
exit 1
fi
关键点：
- 用
php -r直接调extension_loaded()，比php -m | grep更准（避免子串误匹配） - 检查项应和
composer.json中require的ext-*完全一致（如ext-gd→gd） - 不要在脚本里自动
apt install—— 不同环境策略不同（Docker vs. bare metal），只负责报错+提示
为什么不能用 --ignore-platform-reqs 绕过并上线？
加 --ignore-platform-reqs 确实能让 composer install 成功，但后续 php artisan serve 或 php index.php 仍会因 Class not found 或 Call to undefined function 直接 fatal error。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
典型场景：
-
intervention/image声明"ext-gd": "*"，跳过检查后装上了，但运行时调用imagecreatefromjpeg()就崩 -
amphp/amp依赖ext-sodium，跳过之后启动协程直接抛Function sodium_crypto_secretbox() not found - Docker 构建时用了
--ignore-platform-reqs，镜像跑起来才发现扩展根本没编译进 PHP
真正安全的做法：把扩展安装步骤写进 Dockerfile 或部署脚本，而不是靠跳过检查来“假装解决”。
PECL 安装 vs. 系统包管理器，选哪个？
优先用系统包管理器（apt install php-redis、yum install php-pecl-redis），除非你要特定版本或 PECL 尚未打包。
原因：
- 系统包已预编译、带依赖闭环（如
php-redis自动拉libhiredis），PECL 需手动装php-dev、gcc、make - 系统包更新由 OS 统一维护，PECL 包容易滞后（例如 PHP 8.6 发布后，PECL 上的
swoole可能还不兼容） - PECL 安装后常需手动改
php.ini，而系统包通常自动写入/etc/php/*/mods-available/并启用符号链接
例外情况：需要从 GitHub 主干编译最新版（如调试中的 ext-protobuf），才走 phpize && make && make install 流程。
最易被忽略的点：PHP CLI 和 FPM 的 php.ini 路径可能不同，php --ini 和 php-fpm -i | grep 'Loaded Configuration File' 必须都验证；否则脚本检测通过了，Web 请求仍失败。
