加--ignore-platform-req=php仅跳过PHP版本校验，不解决运行时兼容性问题：低版本PHP执行高版本语法（如match）、函数（如str_contains）或扩展行为差异仍会Fatal error；它保留扩展检查，比--ignore-platform-reqs更安全，但需确认代码实际未使用高版本特性。
为什么加 --ignore-platform-req=php 仍可能运行失败
跳过 PHP 版本检查只让 composer install 走通，不等于代码能跑。比如一个包用了 match 表达式（PHP 8.0+），你在 PHP 7.4 上装完，require 时直接 Fatal error: Uncaught Error: Undefined constant。
常见风险点：
- 语法层面：箭头函数、枚举、只读属性等高版本特性在低版本解析即报错
- 函数调用：
str_contains()在 PHP 8.0+ 才内置，低版本需 polyfill 或手动实现 - 扩展行为差异：PHP 8.1 的
DateTime构造器更严格，旧版容忍空字符串，新版直接 throw
真正要确认的不是“能不能装”，而是“会不会执行到那行代码”。查目标包的 src/ 和 CHANGELOG 比加参数更重要。
什么时候该用 --ignore-platform-req=php，而不是 --ignore-platform-reqs
两者区别很实际：--ignore-platform-reqs 会同时跳过 ext-gd、lib-iconv 等所有平台项，容易掩盖真实缺失的扩展；而 --ignore-platform-req=php 只动 PHP 版本，其他照常校验。
立即学习“PHP免费学习笔记（深入）”；
适用场景：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- CI 流水线中 PHP 版本和生产环境不一致，但扩展齐全，只需绕过版本号校验
- 本地开发用 PHP 8.3.0RC1，而依赖包要求
"php": "^8.2"，RC 版本被 Composer 拒绝但实际兼容 - 团队约定统一用 PHP 8.2，但某成员临时切到 8.1 调试，确认无新语法后快速验证
错误做法：只写 --ignore-platform-req（不带等号和值），这等价于 --ignore-platform-reqs，会忽略全部——很多线上事故就从这里开始。
config.platform.php 是长期方案，但别乱写
在 composer.json 里加 "platform": {"php": "8.2.0"}，会让 Composer 始终按这个版本解析依赖，效果比命令行参数更稳定，适合团队统一环境。
但要注意：
- 它骗的是整个依赖解析过程，不是单次安装。如果设成
"php": "7.4.0"，Composer 可能选一个早已废弃的老版本包，哪怕你本地是 PHP 8.3 - 不能解决 runtime 问题：设成
"php": "8.2.0"并不代表你真有ext-opcache或ext-pdo_mysql -
composer update --lock比盲目改platform更安全——它只更新 lock 文件里的版本约束，不重算依赖树
vendor/bin 工具报错，跟 --ignore-platform-req=php 无关
像 phpunit、larastan 这类可执行文件，启动时自己会校验 PHP 版本（通过 PHP_VERSION_ID 或 version_compare()），--ignore-platform-req=php 对它们完全无效。
此时要：
- 看工具自身的 CLI 参数，例如
phpunit --no-configuration可能跳过某些检查 - 降级工具版本：修改
require-dev中的版本约束，比如把"phpunit/phpunit": "^10.0"改成"^9.6" - 确认是否真需要它：有些静态分析工具在低版本 PHP 下功能受限，强行绕过不如换方案
最易被忽略的一点：跳过安装检查后生成的 composer.lock 文件，可能包含无法在目标环境运行的包组合。上线前必须在真实环境中 composer install 验证一次，而不是只信 CI 构建成功。
