require.php 必须显式声明，否则 platform 配置只是摆设；composer 仅依据 require 中 "php": "^8.2" 等约束与 php -v 硬比对来校验安装门槛，config.platform.php 仅影响依赖解析，不校验真实环境，也不阻止运行时崩溃。
require.php 必须显式声明，否则 platform 配置只是摆设
很多人以为在 config.platform.php 里写了 "8.2" 就能拦住不兼容包，结果上线直接 ParseError: syntax error, unexpected token "match"。根本原因是：Composer 只有在 require 字段里看到 "php": "^8.2"，才会在安装/更新时拿它跟 php -v 硬比对——不匹配就报错退出。而 config.platform.php 只影响依赖解析逻辑，不校验你本地真实环境，也不阻止已装包运行时崩溃。
-
require中的php是项目级契约，声明“我这段代码需要什么 PHP 能力” -
config.platform.php是解析期模拟，仅用于 CI 或低版本开发机上预演目标环境 - 两者必须共存：
require定底线，config.platform辅助跨环境一致
别信“能跑就行”，PHP 8 运行时语义变更会静默击穿
有些包没在 composer.json 里声明支持 PHP 8，但实际代码碰巧能跑——这很危险。PHP 8 的 TypeError、ValueError 提升、object 类型严格化、__toString() 必须返回 string 等行为，会让旧包在运行时突然崩掉，且错误位置远离调用点，极难定位。
- 检查 Packagist 页面的 “Requires” 栏，确认依赖包明确写了
"php": "^8.0"或类似范围 - 避免临时加
--ignore-platform-reqs上生产，它跳过所有平台检查，等于主动放弃防护 - v1 版本的
monolog/monolog即使能跑，也因未声明 PHP 8 支持，会被 Composer 排除；必须升到 v2+ 才算真正适配
composer.lock 不是快照，它是环境一致性契约
同一份 composer.lock 在 PHP 8.1 和 8.2 下可能解析出不同结果，尤其当其中某些包的 require.php 写的是 "^7.4 || ^8.0" 这种宽泛范围时。Composer 2.9.6 的 SAT 求解器会根据当前 PHP 版本动态选择满足条件的版本，导致 lock 文件失去可重现性。
- PHP 小版本升级后，必须重新运行
composer update --lock或至少composer install --no-dev验证生产依赖是否仍成立 - CI 流水线里应固定 PHP 版本（如 GitHub Actions 用
php-version: '8.2'），避免因环境漂移导致 lock 解析失败 - 团队成员本地 PHP 版本不一致时，
composer.lock里的platform字段不会自动同步，需靠文档或 pre-commit hook 强制校验
开发阶段最容易忽略的陷阱：require-dev 是隐形炸弹
报错显示 laravel/sanctum 装不上？真正卡住的可能是 phpunit/phpunit 带进来的老版 symfony/http-kernel，而它又和新框架要求的版本冲突。开发依赖不是“只在测试时用”，它的传递依赖会污染整个解析空间。
- 执行
composer show --tree | grep -A5 -B5 "symfony/"快速扫清 dev 工具链引入的隐式强约束 - 把高耦合测试工具（如
orchestra/testbench）统一放在根项目的require-dev，别分散在子模块里 - CI 中加一步
composer install --no-dev，验证生产依赖能否独立成立，排除 dev-only 包干扰
require.php 没写、composer.lock 没随 PHP 版本演进、require-dev 里藏着没人看的传递依赖——这些点不盯紧，再新的 PHP 版本也救不了。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
