Composer platform config部署环境 PHP 版本不一致怎样提前发现怎样完成一个可复用的最小示例

Composer 的 config.platform.php 可以让依赖解析按指定的 PHP 版本进行，但它不会安装或切换 PHP，也不能证明部署机器符合要求。提前发现差异需要两层控制：在开发环境按目标平台生成锁文件，再在目标 PHP 环境运行 check-platform-reqs，读取真实 PHP 与扩展是否满足锁文件要求。

Composer 官方地址：https://getcomposer.org/

先保护锁文件与部署平台的一致性

这里的风险是平台漂移：开发机 PHP 较新，解析到的依赖在部署机上无法运行；或者容器装有扩展，实际 PHP-FPM 却没有加载同一扩展。保护对象是 composer.json、composer.lock 和真实部署平台，不是单纯让安装命令显示成功。

下面假设项目以 PHP 8.2.0 作为最低兼容基线。这是教学版本值，不是部署版本推荐。实际应选择团队仍维护并受支持的目标版本，在同一系列使用合适的补丁版本，另行验证应用兼容性。

用平台配置限制依赖解析的目标

在一个独立演示目录保存以下 composer.json。它不引用第三方包，便于只观察平台要求：

{
  "name": "demo/platform-boundary",
  "require": {
    "php": "^8.2",
    "ext-json": "*"
  },
  "config": {
    "platform": {
      "php": "8.2.0"
    }
  }
}

require.php 是项目支持范围，config.platform.php 是解析器使用的模拟平台版本。真实 PHP 仍是运行 Composer 的那个解释器。require 中 ext-json 表达真实依赖；不要在 platform 中虚构一个生产机不存在的扩展来消除安装失败。

# 在开发或依赖更新环境生成演示锁文件
composer update --no-interaction
# 查看 PHP 平台约束以及实际使用的 Composer 配置来源
composer config --list --source

应保存并提交 composer.json 与 composer.lock。已有项目合并 config.platform 后，需要在受控依赖更新流程中重新解析并审阅锁文件差异；只改 JSON、不更新锁文件，不能保证旧的依赖集合已按新平台重算。部署环境应使用 install，而不是临时 update 改变依赖集合。

在目标 PHP 中检查锁文件要求

让运行检查的 PHP 与生产使用的 PHP 尽量一致，例如在同一运行镜像中执行：

#!/usr/bin/env bash
# 任一平台检查或安装命令失败都停止此部署阶段
set -euo pipefail

# 按锁文件读取生产依赖的平台要求，并检测真实解释器及扩展
composer check-platform-reqs --lock --no-dev

# 使用已经提交的依赖集合，不在部署时重新求解版本
composer install --no-dev --no-interaction --prefer-dist

# 安装后再针对已安装依赖确认实际平台
composer check-platform-reqs --no-dev

check-platform-reqs 会忽略 config.platform 的模拟值，检查真实 PHP 和扩展。命令遇到不满足要求的项目应以失败状态阻断当前部署阶段。这里给出的是读者执行流程，本文没有运行 Composer、安装包或检查本机环境，也没有伪造通过回执。

当 composer 命令指向另一个 PHP 时，应使用目标解释器显式运行 composer.phar，例如用团队固定的 PHP 可执行文件路径调用。CLI 检查成功只说明该 CLI 平台满足依赖声明；PHP-FPM 的扩展、配置和启动参数仍需在相应运行环境核对，不能由 CLI 成功直接外推。

给差异分层，避免用忽略参数掩盖问题

不要把 --ignore-platform-reqs 作为部署成功的常规条件。它绕过了依赖声明的保护，不能解决运行时缺类、缺扩展或语法不兼容。若只要知道谁要求了某个 PHP 版本，可通过依赖诊断查看约束来源，而不是先移除约束。

记录哪些信息才能复现部署判断

保留 PHP 与 Composer 版本、扩展清单、配置来源、锁文件对应提交和检查退出状态；记录不应包含仓库认证信息。平台配置帮助解析依赖，真实平台检查帮助阻止错误发布，业务测试则确认声明之外的实际行为，三者作用不同。

平台兼容检查也不是依赖漏洞审计或应用安全认证。即使所有声明满足，未声明的扩展依赖、外部二进制和应用使用的新语法仍可能造成问题。应把目标 PHP 纳入业务测试，不应把一个检查命令扩大成“上线必定安全”的保证。

platform.php 能否替代 require.php

不能。前者模拟解析平台，后者声明项目要求。只设置模拟值而不声明应用最低版本，会让项目契约缺少必要信息。

需要兼容多个 PHP 版本怎么办

可按最低兼容平台约束依赖解析，再在目标版本矩阵中安装和运行业务测试。最低平台求解不是所有更高版本都兼容的证明，尤其要关注上限约束和行为变化。

官方 platform 配置：https://getcomposer.org/doc/06-config.md#platform；真实平台检查命令：https://getcomposer.org/doc/03-cli.md#check-platform-reqs。