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-redismissing → 安装扩展（sudo apt install php-redis或启用extension=redis.so） -
lib-xxx不可用：如lib-curlmissing → 检查系统 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），它只揪出硬性缺口。所以别只靠它判断安全性或性能，但它确实是上线前最轻量、最可靠的环境快照校验手段。
