composer install 时被跳过的包由 config.platform.php 和 require.php 兼容性共同决定：优先采用 platform.php 指定的完整 PHP 版本（如 "8.1.25"），不匹配该版本要求的包（即使本地 PHP 更高）将被排除；运行 composer show php 可查看实际解析所用平台版本。
Composer 不会“自动筛选”包——它只根据 config.platform.php 或当前运行环境的 PHP 版本，去 Packagist 上匹配满足 require.php 约束的包版本。所谓“自动”，其实是依赖解析时的被动过滤，不是主动扫描或预判。
composer install 时哪些包被跳过？看 platform.php 和 require.php 是否对齐
关键不是“当前 php -v 是多少”，而是 Composer 解析时认定的“目标平台 PHP 版本”。这个值优先来自 config.platform.php，其次才是运行时 PHP 版本。
- 运行
composer show php查看当前解析所用的平台 PHP 版本（不是系统版本） - 如果
composer.json中"require": {"php": "^8.1"}，但config.platform.php设为"7.4.33"，那么所有要求 PHP 8.1+ 的包版本都会被排除，哪怕你本地是 PHP 8.2 -
config.platform.php必须写完整版本号（如"8.1.25"），写"8.1"或"^8.1"会被忽略 - 临时覆盖可用：
composer install --platform=php:8.2，适合 CI 构建中快速验证兼容性
为什么 composer outdated 显示一堆“红色更新”，但 install 却不升级？
因为 outdated 检查的是 Packagist 上所有满足当前 require 约束的**可用版本**；而 install 或 update 实际安装时，还受 config.platform.php + 当前锁文件 + 依赖冲突三重限制。
- 例如：你的
composer.json写着"monolog/monolog": "^2.0"，outdated显示 v3.0 可用（红色），但若 v3.0 要求php: ^8.0，而你设了config.platform.php = "7.4.33"，那 v3.0 根本不会进入候选列表 -
composer update monolog/monolog也不会装 v3.0，除非你先改config.platform.php或删掉该配置再跑update --lock - 想强制看“如果不设 platform，能升到哪”，可加
--ignore-platform-req=php，但仅用于诊断，不要提交到生产
搜索包时怎么避开 PHP 版本踩坑？
别等 require 失败才反应——搜包阶段就要确认兼容性。
立即学习“PHP免费学习笔记（深入）”；
- 用
composer search cache redis找到候选后，立刻执行composer show -a predis/predis，看输出里requires php行是否包含你锁定的版本（如^7.4 || ^8.0） - 注意有些包在 v1.x 支持 PHP 7.2，v2.x 起只支持 PHP 8.0+，
show -a会列出所有历史版本及其 PHP 约束 - 如果项目锁定了
config.platform.php = "7.4.33"，就别选标着php: ^8.1的包，哪怕它最新、stars 最多 - Packagist 网页端包详情页的 “Requires” 区域显示的是 latest stable 版本的 PHP 要求，不一定代表旧版也兼容，务必用
show -a验证具体版本
真正容易被忽略的是：一旦设置了 config.platform.php，它不仅影响 install，还会让 outdated、require 推荐、甚至 composer suggest 全部按这个“虚拟平台”来判断。很多人调完就忘了这层全局约束，结果在不同环境里行为不一致。
