Composer check-platform-reqs –lock 检查锁文件环境要求【技巧】

composer check-platform-reqs –lock 的核心作用是用 composer.lock 中记录的精确包版本，校验当前 php 环境是否满足所有已安装依赖的运行要求。

composer check-platform-reqs --lock 的核心作用是：**用 composer.lock 中记录的精确包版本，校验当前 PHP 环境（含扩展、PHP 版本、INI 配置）是否满足所有依赖的运行要求**。它不检查 composer.json 的声明，只看锁文件里“实际装上的东西”需要什么。

为什么 --lock 参数不能省？

不加 --lock 时，composer check-platform-reqs 默认只读 composer.json，仅校验你“想装”的包的声明要求（比如 "php": "^8.1"），但忽略实际安装的包可能引入的更严苛依赖（例如某个 v2.5.0 的包悄悄要求 ext-gmp，而 v2.4.0 不要）。加了 --lock 才真正反映生产环境的真实约束。

• CI/CD 流水线部署前必须加 --lock，否则可能上线后报 class not found 或 Call to undefined function gmp_init()
• 本地开发切换 PHP 版本后，用 --lock 能立刻发现扩展缺失（如从 PHP 8.1 升到 8.3 后 ext-apcu 被移除）
• composer install 成功 ≠ 运行时安全；check-platform-reqs --lock 是最后一道环境兜底检查

常见失败场景和对应处理

输出中出现 missing 行即表示不满足。典型情况包括：

• php 版本不匹配：锁文件里某包要求 php >=8.2.0，而当前 php -v 是 8.1.28 → 升级 PHP 或降级该包（需改 composer.json 并重生成 lock）
• ext-xxx 缺失：如 ext-redis missing → 安装扩展（sudo apt install php-redis 或启用 extension=redis.so）
• lib-xxx 不可用：如 lib-curl missing → 检查系统 curl 开发库是否安装（libcurl4-openssl-dev），非 PHP 扩展本身
• ini-setting 错误：如 memory_limit = -1 但某包要求 memory_limit >= 512M → 修改 php.ini 或运行时覆盖（php -d memory_limit=512M ...）

和 composer install --dry-run 的区别

check-platform-reqs --lock 只做静态环境比对，不解析依赖图、不下载包、不写文件，毫秒级完成；而 --dry-run 会模拟整个安装流程（包括平台检查、版本解析、冲突检测），耗时长且可能因网络或镜像问题中断。二者目的不同：

• 验证「当前环境能否跑已部署的代码」→ 用 check-platform-reqs --lock
• 验证「当前环境能否成功安装新依赖」→ 用 install --dry-run
• 两者都失败，说明环境严重不兼容；仅前者失败，说明代码已部署但环境被改动（如运维升级了 PHP 主版本）

真正容易被忽略的是：这个命令不会警告「过时但兼容」的扩展（比如你装了 ext-mbstring 8.1.0，而包只要求 >=7.4.0），它只揪出硬性缺口。所以别只靠它判断安全性或性能，但它确实是上线前最轻量、最可靠的环境快照校验手段。