composer报ext-zip缺失但php -m可见，通常因composer与php命令调用不同php二进制；需用which php确认路径并统一检查；platform配置会覆盖真实环境校验，ci中适用但开发建议禁用。
composer check-platform-reqs 报错说 ext-zip 不满足，但 php -m 确实列出了 zip
常见现象是 composer check-platform-reqs 显示 ext-zip: * (missing)，而你执行 php -m | grep zip 却能看到 zip。这通常不是扩展没装，而是 Composer 用的 PHP CLI 版本和你检查时用的不是同一个。
实操建议：
- 运行
which php和composer config --global bin-dir，确认 Composer 调用的是哪个php - 直接用
php -v和php -m检查 —— 但必须用和 Composer 启动时完全相同的二进制路径，比如/usr/bin/php -m或/opt/homebrew/bin/php -m - macOS 上 Homebrew 安装的 PHP，常因 PATH 顺序导致 CLI 默认用系统自带旧版（不带 zip），而
php -v看到的是新版本 - Windows 用户注意：Composer 可能调用
C:\php\php.exe，而命令行默认是C:\xampp\php\php.exe，两者扩展目录不同
check-platform-reqs 和 require 的 platform 配置冲突怎么办
当你在 composer.json 里写了 "platform": {"php": "8.1.0"}，但本地是 PHP 8.2，check-platform-reqs 仍会按平台配置校验，而不是真实环境。
实操建议：
-
"platform"是用来“假装”环境受限的，仅用于构建或 CI 场景；它会让check-platform-reqs检查这个假定版本，而非真实 PHP 版本 - 想验证真实环境，就删掉
"platform"段，或临时加--no-platform-check（但此参数只跳过平台检查，不改变check-platform-reqs行为） - CI 中常用
"platform": {"php": "8.1"}+check-platform-reqs组合，确保开发机不会误装仅支持 8.2 的扩展 - 本地开发建议不配
"platform"，否则容易掩盖真实兼容问题
为什么 check-platform-reqs 不报 openssl 扩展缺失，但 install 时却失败
check-platform-reqs 只检查 require 和 require-dev 中明确声明的扩展依赖，不扫描包内部代码实际调用的函数（比如某包在 src/ 里用了 openssl_encrypt()，但 composer.json 没写 "ext-openssl": "*"）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
实操建议：
- 它只读
composer.json的require字段，不解析 PHP 代码；所以漏声明 = 漏检查 - 有些包把扩展依赖写在
conflict或provide里，check-platform-reqs完全无视这些字段 - 真实场景中，更可靠的手段是跑一次
composer install --dry-run，它会触发 autoloader 和部分扩展加载逻辑，比纯静态检查更早暴露问题 - 若你维护一个包，务必在
composer.json的require中补全所有硬依赖扩展，否则下游无法被check-platform-reqs正确识别
check-platform-reqs 在 Docker 构建中总失败，但本地 OK
Docker 构建时常见错误是 ext-pdo_mysql: * (missing)，但 Dockerfile 明明装了 pdo_mysql。根本原因是 Composer 运行时 PHP 配置文件（php.ini）没加载扩展，或扩展 .so 文件路径不对。
实操建议：
- 在
Dockerfile中，docker-php-ext-enable pdo_mysql必须在composer check-platform-reqs之前执行，且不能依赖 ENTRYPOINT 脚本延迟加载 - 检查
php --ini输出的配置路径，确认docker-php-ext-enable生成的 ini 文件（如20-pdo_mysql.ini）确实在该目录下，并被 PHP 加载 - Alpine 镜像要注意：
php82-pdo-mysql包名和扩展名可能不一致，php -m看不到pdo_mysql，得用php -m | grep pdo，因为 Alpine 下它常显示为pdo - CI 中建议把
check-platform-reqs放在composer install前，但放在所有docker-php-ext-*命令之后，顺序不能错
平台检查不是魔法，它只认 composer.json 写死的依赖、当前 PHP CLI 的扩展列表、以及是否加载了对应 ini 配置——三者缺一不可。最容易被忽略的是 PHP CLI 二进制路径和 ini 加载路径的隐式差异，尤其在多版本共存或容器环境下。
