应直接调用目标PHP二进制执行composer install，如Linux/macOS用/usr/bin/php8.2 composer install，Windows用"C:\php\php82\php.exe" composer install，并确保php -v、shebang路径与composer config platform.php三者一致。
composer install 报 “requires php ^8.1” 但 php -v 是 8.2 怎么办
这不是 Composer 故意卡你，而是它实际调用的 PHP 解释器和终端里 php -v 显示的不是同一个。常见于 alias、wrapper（如宝塔面板封装脚本）、PATH 顺序劫持或 CI 环境中 php 和 composer 分别安装导致版本错位。
验证方法：head -n1 $(which composer) 查看 shebang 行；连续执行两次 php -v（一次在 composer --version 前，一次之后），输出不同就说明被 wrapper 接管了。
- 可靠写法：直接指定 PHP 路径运行，例如
/usr/bin/php8.2 composer install（Linux/macOS）或"C:\php\php82\php.exe" composer install（Windows） - CI/CD 中务必前置
php -v打日志，确认生效版本 -
COMPOSER_PHP=/usr/bin/php8.2 composer install可用，但注意它不传递给 scripts 里显式的php xxx.php，那些地方必须硬编码路径
config.platform.php 该不该设、什么时候设
config.platform.php 是 Composer 唯一允许你“声明目标平台 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 ——match、readonly等语法在 7.4 里根本不存在，运行即报错 - 把该配置提交到团队仓库，队友环境不统一，有人
composer install成功但一运行就ParseError - 设置了却没跑
composer update --lock，导致composer.lock还记着旧版本包
扩展缺失导致的 “platform-reqs” 冲突怎么查
报错里出现 ext-curl、ext-mbstring 或 ext-xml 不满足，不是 Composer 在挑刺，而是它读取了当前 PHP 实际加载的扩展列表（通过 get_loaded_extensions()），和 composer.json 里 require 下的 ext-xxx 约束比对失败。
排查步骤：
- 运行
php -m看当前 PHP 加载了哪些扩展 - 运行
composer show --platform确认 Composer 认为的平台能力是否和php -m一致 - 检查是否用了多个 PHP 版本共存管理工具（如
update-alternatives、phpenv、Homebrew），它们可能只改了php命令，但没同步更新php-config或扩展配置目录 - Docker 环境中，确保
Dockerfile里apt-get install或docker-php-ext-install步骤完整，且顺序正确（有些扩展依赖其他扩展先装）
vendor/autoload.php 在多 PHP 版本下为何有时失效
vendor/autoload.php 本身不绑定 PHP 版本，但它生成的静态映射文件（如 vendor/composer/autoload_static.php）会依赖 PHP 的反射行为。PHP 8.0+ 对 ReflectionClass::getMethods() 等 API 的返回结构有调整，若用 PHP 7.4 生成 autoload 文件后放到 PHP 8.2 下运行，某些类可能无法被正确加载。
根本原因不是自动加载器坏了，而是：
- 不同 PHP 版本下生成的
autoload_static.php或autoload_classmap.php因反射行为差异而失效 - 同一服务器部署多个项目（如 TP5 和 TP6），
COMPOSER_HOME共享导致全局缓存污染，两个项目的 autoload 文件互相覆盖 - 未清理旧缓存就重装：删了
vendor/但没清~/.composer/cache，Composer 复用旧缓存生成 autoload
解决办法只有两个：严格按目标 PHP 版本生成 autoload（即用对应版本的 php 执行 composer dump-autoload），以及避免共享 COMPOSER_HOME。
