"php"字段是项目对PHP版本的硬性声明，仅在install/update时生效，Composer据此筛选兼容的包版本，不校验扩展加载，也不影响运行时。
Composer 不会自动适配你的 PHP 版本，它只严格按你“告诉它”的版本去选包。错配时不是警告，是直接中断 install/update。
composer.json 里的 "php" 字段到底起什么作用
这是项目对运行环境的**硬性声明**，不是建议。比如 "php": "^8.1" 意味着 Composer 在解析依赖树时，只会考虑那些明确声明支持 PHP 8.1+ 的包版本（如 monolog/monolog v3.0+），哪怕你本地是 PHP 8.2，它也不会选一个只标了 "php": "^8.0" 的 v2.x 版本——即使语法上能跑。
- 该字段只在
composer install或composer update阶段生效，不影响运行时 - 它不校验扩展是否加载，只看包元数据中的
require.php - 如果写成
"php": ">=8.1.0 ，能避免意外升到不兼容的 8.3.x 小版本 - 别用
~8.1：它等价于>=8.1.0 ，会错过 8.2.x 的安全修复
config.platform.php 是“编译期欺骗”，不是运行时补丁
config.platform.php 的唯一作用，是在依赖解析阶段覆盖 PHP_VERSION 常量，让 Composer “以为”自己跑在某个版本上。它**完全不改变实际执行环境**。
- 适用场景极窄：你在 PHP 7.4 的机器上，但要为 PHP 8.2 的生产服务器打包 vendor —— 此时设
"platform": {"php": "8.2.0"}+composer update --lock才有意义 - 禁用场景很常见：本地 PHP 是 7.4，却设了
"platform": {"php": "8.2.0"}后直接跑 Laravel 11，match表达式一执行就ParseError: unexpected token "match" - 该配置写入
composer.json后，必须跟composer update --lock，否则composer.lock仍记录旧平台下的包版本 - 别提交到团队仓库：队友用 PHP 8.2 开发，你用 7.4 提交了
"platform": {"php": "7.4.33"}，他composer install成功，但一调用新语法就崩
为什么显式调用 php 二进制比改系统默认更可靠
Composer 完全依赖 shell 中 php 命令指向的可执行文件。改 update-alternatives 或 brew link 会影响全局，而显式路径能隔离项目。
立即学习“PHP免费学习笔记（深入）”；
- Linux/macOS：用
/usr/bin/php8.2 composer install，不依赖当前$PATH中的php - Windows：用
"C:\php\php82\php.exe" composer install，引号防空格路径出错 - CI 脚本中务必前置
php -v打日志，确认实际生效版本，别只信配置项 - IDE（如 PHPStorm）可能缓存 CLI 解释器路径，切换 PHP 后需手动刷新设置
vendor/autoload.php 加载后才报错？那是语法已埋伏好了
vendor/autoload.php 本身不校验 PHP 版本，但它加载的类文件可能在 require、use 或首次调用方法时触发语法错误。
- 典型表现：
ParseError: syntax error, unexpected token "string"（PHP 8.0 联合类型）、Fatal error: Uncaught Error: Unknown named parameter（PHP 8.0 命名参数） - 用
php -l vendor/some/package/src/Class.php可快速验证单个文件是否兼容当前 PHP - 某些包用
class_exists()延迟检测，错误不会出现在 autoload 阶段，而是走到业务逻辑才暴露 - 升级 PHP 后，应删掉
composer.lock和vendor/，再重新composer install—— 复用旧 vendor 是最常被忽略的坑
