应显式指定目标PHP路径执行composer install，如Linux/macOS用/usr/bin/php8.1 composer install，Windows用"C:\php\php81\php.exe" composer install，并确保php -v、which php与composer实际调用路径一致；config.platform.php仅用于CI或打包场景，不可替代真实PHP版本匹配。
composer install 报 “requires php ^8.1 but your PHP version (7.4.33) does not satisfy” 怎么办
这不是 Composer 在刁难你，而是它正在用 php -v 输出的真实 CLI 版本校验 composer.json 里写的 "php": "^8.1"。不匹配就停，不装、不妥协。
常见误操作包括：
- 直接改系统默认 PHP（比如用
update-alternatives），结果把其他项目或 CI 脚本搞崩 - 看到报错就加
--ignore-platform-reqs，结果vendor/里塞进一堆 PHP 8.1 语法（如match表达式），一运行就Fatal error: syntax error, unexpected token "match" - 只改了
composer.json里的"platform": {"php": "8.1"}，却没跑composer update --lock，导致composer.lock还记着旧包
正确做法是让 Composer 明确知道你要按哪个 PHP 版本解析依赖：
- Linux/macOS：
/usr/bin/php8.1 composer install - Windows：
"C:\php\php81\php.exe" composer install - CI 脚本中务必前置
php -v打日志，确认生效版本
config.platform.php 是“假装”，不是“运行时兼容”
config.platform.php 只影响依赖解析阶段（install/update），不改变实际运行环境。它适合的场景非常窄：
立即学习“PHP免费学习笔记（深入）”；
- 你在 PHP 7.4 的开发机上，但要为 PHP 8.2 的生产服务器提前生成兼容的
vendor/目录（比如打部署包） - CI 流水线中明确指定目标环境 PHP 版本，且所有包都已验证过兼容性
禁用场景更关键：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 本地 PHP 是 7.4，却设
"platform": {"php": "8.2"}后直接跑 Laravel 11 ——readonly、enum、命名参数在 7.4 里根本不存在 - 把这个配置提交到团队仓库，而队友环境不统一，导致有人
composer install成功但运行时报错
设置方式（仅限当前项目）：composer config platform.php "8.2.0"，之后必须跟 composer update --lock 重写锁文件。
刚 clone 项目就 composer install 失败？先查这三件事
不是网络慢、不是镜像挂了，大概率是交付前漏掉了关键文件或配置：
- 确认
composer.lock文件存在且已提交到 Git —— 如果不存在，composer install会 fallback 到update行为，结果不可控 - 检查
vendor/目录是否被.gitignore错误排除，导致 CI 拉不到完整代码树 - 验证
composer.json里是否有拼写错误的包名（比如"laravel/framework": "10.x-dev "多了个空格），这种错误在install阶段不会报，但后续autoload会失效
composer install 成功不代表能跑起来。类找不到、命令不存在、php artisan 报错，90% 是因为 autoload 没生效或路径映射错位——别急着重装，先看 vendor/autoload.php 是否存在，再跑 composer dump-autoload。
PHP 版本升级后，怎么让依赖不崩
升级 PHP 前，先确认项目中所有已安装的包是否支持目标版本：
- 运行
composer show --vendor-filter=installed --format=json导出当前依赖列表，结合其composer.json中的"php"字段判断兼容性 - 重点关注长期未更新或明确声明不支持新版 PHP 的扩展包
- 用
composer why-not vendor/package:version定位阻塞链，而不是删composer.lock重算
真要升级依赖，避免一次性大范围变更：
- 先锁定依赖，仅升级 PHP 并测试功能是否正常
- 再逐个更新主要组件：
composer update monolog/monolog --with-dependencies - 升级后立刻
git diff composer.lock，确认只有预期的包和其直系依赖被改动
最常被忽略的一点：切换 PHP 版本后，必须删除 vendor 和 composer.lock 并重新 composer install。否则 autoload_classmap.php 因生成环境差异（如语法、反射、扩展路径）将在运行时报错。
