在 Docker 容器里执行 check-platform-reqs 才算数，因为该命令只检测当前 CLI 环境的 PHP 版本、扩展和配置，而容器内环境与宿主机完全隔离；宿主机检查通过不代表容器能正常运行，必须进容器或在构建/CI 阶段针对目标环境执行校验。
为什么在 Docker 容器里跑 check-platform-reqs 才算数
宿主机上执行 composer check-platform-reqs 的结果对容器内运行完全无效。它只检测当前 CLI 环境（即你敲命令时用的 PHP），而 Docker 容器里的 PHP 版本、扩展、php.ini 都是独立的。常见错误：Mac 上 php -v 显示 8.2，但容器用的是 php:8.3-apache，此时宿主机检查通过 ≠ 容器能跑。
真正要验证的，是容器启动后那个环境本身。所以必须进容器执行，或在构建阶段就做检查。
- CI 流水线中，应在
docker build后、composer install前，用docker run --rm -v $(pwd):/app -w /app php:8.3-cli composer check-platform-reqs验证 - 本地开发时，先
docker-compose up -d app，再docker-compose exec app composer check-platform-reqs - 如果用多阶段构建，可在 builder 阶段末尾加一行
RUN composer check-platform-reqs，失败则整个镜像构建中断
check-platform-reqs 在容器里报错，但 composer install 却成功了？
这不是 bug，是行为差异导致的误判。根本原因：默认情况下 composer install 不强制校验 platform（除非显式启用 --platform-check 或配置了 "config": {"platform-check": true}），而 check-platform-reqs 是纯平台层只读检查，不依赖 composer.lock，也不做任何降级适配。
典型场景：
- 你的
composer.json写着"php": "^8.3"，但容器里是 PHP 8.2 →check-platform-reqs直接失败 -
composer.lock里锁了一个兼容 PHP 8.2 的旧版包 →install能过，但运行时可能因新语法（如 match 表达式）崩溃 - 容器没装
ext-redis，但项目只在require-dev里声明了predis/predis→check-platform-reqs --no-dev不报，而install默认会装require-dev里的东西
Dockerfile 中怎么安全嵌入 check-platform-reqs 检查
不能只写 RUN composer check-platform-reqs 就完事——它会卡住构建，且错误信息不直观。建议配合明确参数和容错逻辑：
- 始终加
--no-dev：生产镜像不需要 dev 依赖，避免误报ext-xdebug这类仅开发用扩展 - 用
&&连写，让失败立即中断：RUN composer check-platform-reqs --no-dev && echo "✅ Platform OK" - 如果基础镜像已预装扩展但未启用（比如
php:8.3-cli默认不带ext-gd），得先确认是否真的加载：RUN docker-php-ext-install gd && composer check-platform-reqs --no-dev - 避免在最终镜像层执行检查：把它放在 builder 阶段，而不是
FROM php:8.3-apache的运行阶段
容易被忽略的三个容器化陷阱
check-platform-reqs 在 Docker 场景下失效，往往不是命令本身问题，而是环境细节没对齐：
-
config.platform被硬编码成"php": "8.1.0"：容器里明明是 8.1.25，它仍报错。应改用"^8.1"或干脆删掉该配置，靠真实环境检测 - PHP CLI 和 FPM 用不同
php.ini：check-platform-reqs走 CLI，但 Web 请求走 FPM。务必在容器内分别运行php -m | grep mbstring和php-fpm -i | grep mbstring - 扩展名大小写敏感：Dockerfile 里写
docker-php-ext-install intl，但composer.json写的是"ext-INTL": "*"→ 检查直接忽略。统一用小写ext-intl
最保险的做法，是在 CI 中把 check-platform-reqs 和 php -v、php -m 输出一起存为日志片段，出问题时一眼比对，而不是只看红字报错。
