composer check-platform-reqs仅校验当前项目根目录下composer.json中require和config.platform显式声明的php版本与扩展，不检查未声明依赖、web环境、php.ini设置或代码实际调用，故无报错≠可运行。
直接运行 composer check-platform-reqs 只有在项目根目录且 composer.json 显式声明了 PHP 版本或扩展时才有效；否则它什么都不会报，但项目 runtime 仍可能崩溃。
必须在项目根目录执行，且依赖 composer.json 显式声明
这个命令不会向上查找父目录的 composer.json，也不会读取 vendor/ 或 composer.lock。它只看当前目录下的 composer.json 文件中 require 和 config.platform 字段里是否写了平台约束。
- 如果
require里没写"php": ">=8.1"或"ext-zip": "*"，那即使项目实际依赖 zip，check-platform-reqs也完全不检查 -
config.platform是“假装环境”的配置，比如设成"php": "8.1.0"，命令就按这个版本比对，而不是你本地真实的php -v输出 - 拼错字段名（如写成
"platfrom"）会导致配置被静默忽略，检查结果看似正常，实则失效
PHP CLI 和 Web 环境不一致是常见误报根源
check-platform-reqs 总是使用 Composer 当前调用的 PHP CLI 二进制来检查，而你手动执行 php -m 时可能用了另一个版本 —— 这就是为什么它报 ext-zip: * (missing)，但你查又确实存在。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先确认 Composer 用的是哪个 PHP：
which php，再用该路径完整执行：/usr/bin/php -m | grep zip - macOS 上 Homebrew 安装的 PHP 常因 PATH 顺序导致 CLI 默认调用系统旧版（不带 zip），而
php -v看到的是新版本 - Windows 用户注意：
composer可能调用C:\php\php.exe，而命令行默认是C:\xampp\php\php.exe，两者php.ini和扩展目录完全不同
它不检查代码实际调用的扩展，只认 composer.json 的 require
这个命令不会扫描 PHP 源码，也不会解析已安装包的内部逻辑。哪怕某个包在 src/ 里硬调了 openssl_encrypt()，只要它的 composer.json 没在 require 里写 "ext-openssl": "*"，check-platform-reqs 就完全不管。
- 它无视
conflict、provide、require-dev（除非加--no-dev参数）里的平台声明 - 它不验证
php.ini运行时设置，比如memory_limit、opcache.enable、upload_max_filesize，这些得单独用php --ini和php -r 'var_dump(ini_get("memory_limit"))'查 - Web SAPI（如 Apache mod_php / PHP-FPM）和 CLI 使用不同
php.ini，所以命令行通过 ≠ 网页能跑
真正容易被忽略的是：它只告诉你「声明的约束是否满足」，不是「代码能不能跑」。上线前别只信它输出的 OK —— composer install --dry-run 和真实环境下的 phpinfo() 页面，才是更贴近实际的验证手段。
