必须显式声明php版本上限才能真正限制，如"php": ">=8.1.0
直接在 require 里写上限，才是真限制
Composer 不会自动给你加 PHP 版本上限，它只认你明文写的约束。如果你只写 "php": "^8.1"，那 Composer 默认允许装到 8.999.999（只要语义化版本规则没变），根本拦不住 PHP 9.0 出来后误装不兼容包。
真正起作用的写法是显式用比较符组合：
"php": ">=8.1.0 —— 最低 8.1.0，最高不包括 8.4.0，精准框定小版本范围-
"php": ">=8.1.0, !=8.2.5"—— 除掉已知有严重 bug 的具体补丁版 - 避免只写
"php": "8.1"—— 这会被 Composer 解析为^8.1.0，等价于>=8.1.0 ，毫无上限可言
config.platform.php 不是版本锁，是“假装自己是旧环境”
这个配置项常被误称为“锁定 PHP 版本”，其实它完全不干预运行时，只在 composer install 或 composer update 阶段，让 Composer 按你指定的 PHP 版本去查依赖兼容性。比如本地是 PHP 8.3，但生产是 8.1，设 "platform": {"php": "8.1.0"} 后，Composer 就不会选那些只声明支持 "php": "^8.2" 的包。
- 它不能防止你在 PHP 8.3 下跑出语法错误（比如用了
match表达式却声称兼容 8.1） - 它对
require-dev同样生效——可能把 PHPUnit 10（需 PHP 8.1+）换成 PHPUnit 9（PHP 7.3+），导致测试工具链降级 - 如果 CI 脚本里没同步切换真实 PHP 版本，仅靠 platform 掩盖，
php -v和composer show --platform一比就露馅
装不上包？先分清是“真不兼容”还是“假报错”
常见报错 Your requirements could not be resolved to an installable set of packages.，背后往往不是 PHP 版本本身不行，而是某依赖的 composer.json 里写了宽松下限 + 缺失上限（例如 "php": ">=7.4"），结果 Composer 拿最新版去配，发现新版依赖又要求 PHP 8.2+，而你只有 8.1 —— 死循环卡住。
立即学习“PHP免费学习笔记（深入）”；
- 用
composer depends --tree vendor/package找出谁在拖后腿 - 查 Packagist 页面或执行
composer show vendor/package --all | grep php，看哪个历史版本还支持你的 PHP - 临时方案：在
require中硬写老版本，如"laravel/framework": "^8.75"，而非"^10.0" - 伪造
platform是高风险操作——相当于告诉 Composer “我敢跑，你别管”，但 runtime 仍可能炸
CI/CD 和 Docker 里，platform 很有用，但必须配真实版本
在 GitHub Actions 或 GitLab CI 里，platform 的价值才真正体现：你可以用高版本 PHP 安装器（比如 PHP 8.3），但通过 config.platform.php 强制按 8.1 解析依赖，再配合 php-version: '8.1' 确保测试运行在真实目标环境上。
- 不要只在
composer.json里设platform，却不改 CI 的php-version—— 那只是自欺欺人 - Dockerfile 中应明确
FROM php:8.1-cli，而不是FROM php:latest再靠 platform 补救 - 用
composer check-platform-reqs做最后校验，它会对比require声明和当前真实环境，比 platform 更可信
最易被忽略的一点：PHP 版本上限不是写一次就完事的。当项目长期维护，8.4 发布后，你得主动更新 " 为 <code>"；否则旧约束会变成隐形枷锁，既拦不住新问题，也掩盖不了兼容性退化。
