Composer无直接查看平台需求的命令，需通过composer.json的platform字段、composer show已安装包的requires区块、composer why-not分析冲突及depends --tree追溯依赖树动态叠加来综合判断。
Composer 本身不提供直接查看“平台需求”（PHP、扩展、OS 等）的独立命令，但所有平台约束都藏在 composer show 和 composer why 的输出里，关键是要知道查谁、怎么看、为什么容易漏掉。
查当前项目声明的 platform 配置
项目根目录的 composer.json 中如果写了 "platform" 字段，它会覆盖真实环境的 PHP 版本或扩展版本，导致依赖解析结果失真——但 composer show 默认不显示这个配置。
- 用
cat composer.json | grep -A 5 platform直接看原始配置（注意：它可能在config下，也可能在require里写成"php": "^8.1"） -
composer show --platform并不存在，别试；composer config platform只能读取，不能反映实际生效值 - 真正影响安装行为的是
composer.lock里的platform快照，运行composer install时会按它锁定，不是按composer.json实时解析
查某个包要求的 PHP 版本和扩展
一个包是否能在你机器上装，取决于它 composer.json 里 require 的 php 和扩展（如 ext-json），而不是你本地有没有装。这些信息只有在它被安装后才能从 composer show 中提取出来。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先确保包已安装：
composer show vendor/package-name（例如composer show laravel/framework） - 输出中找
requires区块，里面带php或ext-前缀的行就是平台硬性要求 - 如果包没装，
composer show会报错；此时只能去 Packagist 页面手动翻它的composer.json，或用composer show --remote vendor/package-name（仅限 Composer 2.4+） - 注意：
ext-ctype这类是 PHP 内置扩展，ext-gd这类需单独启用，lib-*（如lib-curl）属于系统库，composer show不校验它们是否存在
查冲突源头：为什么某个包死活装不上
最常见的情况是：你本地 PHP 是 8.0，但某个包要求 "php": "^8.1"，而它又被另一个已装包间接拉入——这时 composer install 报错，但错误信息只说“Your requirements could not be resolved”，不指明哪一层卡住了。
- 先跑
composer why-not vendor/package-name:version（例如composer why-not monolog/monolog:^3.0），它会列出所有阻止安装的约束，包括 platform 不匹配 - 输出里看到
php (>=8.1.0)被拒绝，就说明是平台问题；再结合php -v和php -m | grep json对照 - 如果
why-not没输出，试试composer depends vendor/package-name --tree，看是不是某个中间包用了provide声明虚拟平台需求（比如"provide": {"php": "8.0.*"}），这种不会被why-not捕获 - 别信
composer diagnose——它只检查composer.json格式和网络连通性，不验证 platform 兼容性
绕过 platform 检查的临时方案与风险
开发调试时有人会加 --ignore-platform-reqs 强行装，但这只是跳过校验，不解决根本问题：装上的包可能在运行时报 Call to undefined function 或 undefined constant。
-
composer install --ignore-platform-reqs会忽略全部 platform 约束，包括php、ext-、lib- - 更安全的做法是只忽略某一项：
--ignore-platform-req=php或--ignore-platform-req=ext-gd - 一旦用了
--ignore-platform-reqs，composer.lock里记录的 platform 快照就失效了，下次别人install会因环境不同而失败 - CI 流水线里绝对不要用这个参数——它掩盖的是环境不一致问题，不是依赖问题
真正复杂的地方在于：platform 需求不是静态的，它随依赖树动态叠加。一个包自己只要 PHP 8.0，但它依赖的子包要 8.2，那整个链就升到 8.2；而 composer show 只显示单层声明，不递归合并，所以必须靠 why-not 和 depends --tree 交叉验证。
