在Composer配置文件中配置平台伪装版本的方法-composer-PHP中文网

config.platform 必须置于 composer.json 的 config 对象内，值需为完整语义化版本（如"8.1.10"），仅影响 update 时依赖解析，不改变运行环境；命令行 --platform 优先级更高，适合 ci 跨平台构建，但无法模拟 os 或架构。

在composer配置文件中配置平台伪装版本的方法

很多人把 "platform" 直接写在 composer.json 根层级，结果完全不生效。正确位置是 "config" 字段下的子对象。Composer 只认这个路径，其他地方写的 platform 都被忽略。

常见错误写法："platform": {"php": "8.1.10"}（根级，无效）

正确写法：

{
  "config": {
    "platform": {
      "php": "8.1.10",
      "ext-mbstring": "8.1.10",
      "ext-openssl": "8.1.10"
    }
  }
}

命令行方式绕过编辑文件、不污染 composer.json，特别适合 CI 流水线中为不同目标环境生成 lock 文件。

例如，在 GitHub Actions 中为 PHP 8.1 环境生成兼容 lock：

composer update --no-interaction --with-all-dependencies --platform=php:8.1.10 --platform=ext-gd:8.1.10

--platform=php:X.Y.Z 和 --platform=ext-xxx:V 可多次使用，优先级高于 composer.json 中的 config.platform
--platform 在 install 和 update 阶段都生效；而 config.platform 仅在 update 时参与解析
若同时用了 --platform 和 config.platform，前者完全覆盖后者

设了 "php": "8.1.10"，不代表你本地 PHP 7.4 就能跑起来——它只让 Composer “假装”当前是 8.1.10 来选包，不改实际执行环境。

使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。

下载

典型翻车场景：

本地 PHP 8.2，config.platform.php 设为 "8.1.10"，装了 Laravel 10，但代码用了 readonly 属性 → 运行时报 ParseError: unexpected token "readonly"
本地没装 ext-posix，却在 config.platform 里声明了它 → composer install 成功，但运行时调用 posix_getpid() 直接 Fatal error
以为加了 ext-curl 就能用，结果只是跳过了依赖检查，实际 curl 扩展根本没启用（php -m 里看不到）

本质：它只管“能不能选到包”，不管“包装完能不能跑”。真正决定运行能力的是你本地 PHP 版本、已加载扩展、以及 ini 配置是否启用。

想在 macOS M1 上为 Linux ARM64 构建部署包？单靠 config.platform 不够。它没法模拟 OS 类型或架构，只能伪造 PHP 和扩展版本。

比如你写了 "ext-sodium": "8.2.12"，Composer 不知道这是 Linux 还是 Windows 下的 sodium，更不会帮你下载对应平台的二进制。

含原生二进制的包（如 spatie/browsershot、laravel/pail）通常靠 PHP_OS_FAMILY 和 PHP_ARCH 决定下载行为 —— 这些是 PHP 运行时变量，config.platform 完全不碰
真正可靠的跨平台构建方式是：在目标环境镜像里运行 composer install，例如：
```
docker run --rm -v $(pwd):/app -w /app composer:2.7 install --no-dev
```
如果必须本地构建，优先用 --platform 命令行参数 + 显式声明所有目标环境扩展版本，再手动验证关键二进制是否存在