Composer安装失败时应确保其使用正确的PHP版本，可通过显式指定PHP路径或配置platform字段解决，切勿用--ignore-platform-reqs掩盖问题。
Composer 安装失败提示 requirement not met: php >= 8.1 或类似版本不匹配错误时，不能靠绕过环境检测来解决——这会导致依赖安装后运行时报错、扩展无法加载、甚至静默失败。真正有效的做法是让 Composer **看清你实际的 PHP 环境**，或**明确指定它该用哪个 PHP 版本执行**。
确认当前 composer 调用的是哪个 PHP
Composer 是一个 PHP 脚本，它的行为完全取决于它启动时绑定的 PHP 解释器。很多人误以为改了系统 php -v 输出就等于 composer 也用了新版本，其实未必。
- 运行
composer --version后，紧接着执行which composer，查看是否为 Phar 文件（如/usr/local/bin/composer） - 用
head -n 1 $(which composer)查看首行，如果是#!/usr/bin/env php，说明它依赖$PATH中第一个php - 直接运行
php -v和$(which php) -v，确保二者一致；若不一致，composer实际用的很可能是前者路径下的 PHP
强制 composer 使用指定 PHP 版本执行
最稳妥的方式不是改全局配置，而是每次调用时显式指定 PHP 解释器。尤其当你有多个 PHP 版本共存（如通过 phpbrew、asdf、或手动编译）时，这个操作不可跳过。
- 先确认目标 PHP 可执行路径，例如
/opt/php/8.2/bin/php或~/.phpbrew/php/8.2.12/bin/php - 用完整路径调用 composer：
/opt/php/8.2/bin/php composer.phar install（注意：必须用.phar文件，而非 shell wrapper） - 如果使用全局安装的 composer 命令，可临时覆盖：
PHP_BINARY=/opt/php/8.2/bin/php composer install - 避免使用
alias composer='php82 /path/to/composer.phar'类似别名——某些 CI 环境或脚本中 alias 不生效
修改 composer.json 的 platform 配置（仅限构建/CI 场景）
"platform" 是 composer.json 中一个特殊字段，它**欺骗依赖解析器**：告诉 Composer “我声称自己运行在某个 PHP 环境下”，但它**不改变实际执行环境**。仅应在你确定运行时 PHP 版本 ≥ platform 声明值的前提下使用，比如 Docker 构建阶段提前固定了运行环境。
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
立即学习“PHP免费学习笔记（深入）”；
- 在
composer.json的config下添加：
{
"config": {
"platform": {
"php": "8.2.12"
}
}
}
- ⚠️ 这不会让 PHP 7.4 运行需要
mbstring的 PHP 8.2 代码；它只影响依赖下载时的版本决策 - CI 中常见组合：
php:8.2-cli镜像 +"platform": {"php": "8.2"}，防止因本地开发机是 PHP 8.1 导致锁文件生成不一致 - 切勿在
platform中声明高于你部署环境的 PHP 版本，否则上线即 fatal error
为什么不要用 --ignore-platform-reqs
这个 flag 看似快捷，实则是把问题延后引爆。它跳过所有平台约束检查（包括 PHP 版本、扩展是否存在、扩展版本），但 Composer 安装完的包可能在运行时立刻报 Call to undefined function mb_str_split() 或 Class "UnitEnum" not found。
-
--ignore-platform-reqs应仅用于调试、临时验证某包兼容性，**绝不能出现在 CI 脚本或部署流程中** - 它还会导致
composer.lock记录错误的 PHP 平台信息，下次别人拉取 lock 文件时可能因环境不同而重装不一致版本 - 真正的兼容性问题必须由代码适配或环境对齐解决，不是靠忽略来“假装存在”
最常被忽略的一点：很多 PHP 版本不匹配问题，根源不在 Composer 本身，而在于你用 root 权限装了某个 PHP，但普通用户执行 composer install 时加载的是另一个用户的 php.ini，导致扩展未启用、memory_limit 过低、甚至 CLI SAPI 和 Web SAPI 的配置差异引发 autoload 失败。查清 php --ini 输出的实际配置路径，比任何 flag 都管用。
