php版本选择需严格匹配框架与依赖的兼容范围，通过composer.lock或框架文档确认；避免系统默认源安装，推荐ondrej/php ppa或brew；注意php.ini差异及废弃特性。
PHP 版本不能“随便选”，核心原则是：你的应用框架和依赖库决定了可选的最低与最高版本范围，超出这个范围大概率会报错或丢功能。
看 Composer.lock 或框架文档确认兼容版本
现代 PHP 项目几乎都用 Composer 管理依赖，composer.lock 文件里明确记录了每个包实际安装的版本及其 php 平台要求。直接运行：
grep -A5 '"platform":' composer.lock
或者更准一点，查 root require 的 PHP 约束：
composer show --platform | grep php
常见场景包括：
立即学习“PHP免费学习笔记（深入）”；
- Laravel 10 要求
php: "^8.1"，不支持 8.0 或 8.3（除非 patch 后兼容） - WordPress 6.5 官方推荐
PHP 8.0–8.2，已明确不测试 8.3 - 如果你用
ext-redis5.3.7，它只支持到 PHP 8.2；升级到 8.3 就得等新版本发布
避免用系统默认源装 PHP（尤其 Ubuntu/Debian）
Ubuntu 的 apt install php 默认装的是系统维护的旧版（比如 22.04 是 PHP 8.1，但 20.04 是 7.4），且无法并存多个版本。建议：
- 用
ondrej/phpPPA（仅限 Debian/Ubuntu）：sudo add-apt-repository ppa:ondrej/php<br>sudo apt update<br>sudo apt install php8.2 php8.2-cli php8.2-mysql php8.2-curl
- macOS 用
brew install php@8.2，它会软链php到指定版本，且支持多版本共存 - 生产环境强烈建议用
phpbrew或asdf管理多版本，避免污染系统 PHP
php.ini 配置不是装完就完事
不同 PHP 版本的默认配置差异很大，比如 opcache.enable 在 CLI 模式下默认关（8.0+），而 Web SAPI 默认开；date.timezone 在新版中若未设会触发警告。容易踩的坑有：
- 升级后出现
Undefined array key—— 可能是error_reporting默认值变了，8.0+ 默认含E_WARNING，老代码没做键存在性检查 -
mbstring.func_overload在 8.2 中彻底移除，如果项目还依赖它，必须重写字符串处理逻辑 - CLI 和 FPM 的
php.ini是两个文件：/etc/php/8.2/cli/php.ini和/etc/php/8.2/fpm/php.ini，改完要分别重启php-fpm和确认 CLI 是否生效
版本选错最麻烦的不是装不上，而是某些函数静默失效（比如 mysql_connect 在 7.0 就删了，但有些老扩展还在用别名调用），或者类型声明在 8.0+ 严格校验后直接中断执行。动手前务必先跑一遍 php -l 和 composer install --dry-run。
