check-platform-reqs --lock 只检查 composer.lock 中已锁定包声明的 platform 依赖（如 php、ext-zip）与当前环境实际版本是否匹配，不检查 composer.json、不触发解析或更新。
check-platform-reqs --lock 会检查哪些内容？
它只检查 composer.lock 中已锁定的包所声明的 platform 依赖（如 php、ext-zip、ext-mbstring 等），和当前运行环境的实际版本是否匹配。不会检查 composer.json 里的 require，也不会触发依赖解析或更新。
为什么加 --lock 参数后没报错，但项目仍启动失败？
常见原因有：
-
composer.lock里没记录某些扩展（比如包通过require-dev引入、但未在autoload或运行时真正用到，Composer 可能未将其平台依赖写入 lock） - 某些扩展虽已安装，但被禁用（例如
extension=gd.so在php.ini中被注释） - CLI 和 Web SAPI 使用不同
php.ini，composer检查的是 CLI 环境，而 Apache/Nginx 走的是另一个配置 - PHP 版本满足最低要求，但某些函数在特定小版本中被移除（如 PHP 8.2 废弃了
mysql_connect，而 lock 文件不校验函数级兼容性）
如何让 check-platform-reqs --lock 更可靠？
执行前确保：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 用目标环境的 PHP 运行命令：
php -c /path/to/your/web/php.ini /usr/bin/composer check-platform-reqs --lock
- 确认
composer.lock是最新生成的（刚 run 过composer install或update） - 若项目含自定义平台配置（如
"platform": {"php": "8.1.0"}），需确保该值与实际部署 PHP 版本一致，否则--lock会按这个假定值校验，而非真实环境 - 对扩展缺失类错误（如
Class ZipArchive not found），光靠--lock不够，建议配合php -m | grep zip
和php -i | grep 'Loaded Configuration File'
手动验证
和不加 --lock 的区别在哪？
不加 --lock 时，check-platform-reqs 仅读取 composer.json 的 require 和 config.platform，按“理论需求”校验；加了 --lock 才真正反映当前已安装的依赖树实际需要什么——这才是上线前最该验证的场景。
容易忽略的一点：如果 lock 文件里有多个版本的同一扩展要求（比如 A 包 require ext-gd: ^8.0，B 包 require ext-gd: * ），--lock 会取并集校验，但不会告诉你具体哪个包驱动了该要求。
