composer.lock不是“每次install都一样”是因为它会记录php版本和扩展等平台信息，导致跨环境生成不同哈希值；需通过config.platform统一求解环境，并配合composer update --lock刷新platform字段以确保一致性。
composer.lock 为什么不是“每次 install 都一样”就完事？
因为 composer.lock 文件本身会因平台差异而生成不同内容——同一份 composer.json，在 PHP 8.1 和 8.2 下运行 composer update，可能产出两份哈希值不同的 lock 文件。这不是 bug，是 Composer 的正常行为：它默认把当前运行环境的 php 版本、已启用扩展（如 ext-zip、ext-sockets）都写进 lock 文件顶部的 platform 字段，作为依赖求解的输入条件。
一旦 lock 文件里记录了 "php": "8.2.5"，而某位同事用的是 8.1.0，composer install 就会直接报错退出，哪怕所有包版本完全一致。
- 常见错误现象：
Your lock file does not contain a compatible set of packages，但你确认没改composer.json - 根本原因：lock 文件中 platform 声明与当前 PHP 环境不匹配
- CI 流水线在 Linux 上通过，本地 Windows 开发机却失败，往往就是
ext-sockets这类扩展默认状态不同导致的
怎么用 config.platform 强制统一解析环境？
在 composer.json 的 config 段显式声明团队约定的最小平台要求，就能让所有人的 composer update 基于同一套“虚拟环境”求解依赖树，从而产出结构一致的 composer.lock。
示例（推荐写法）：
{
"config": {
"platform": {
"php": "8.1.0",
"ext-zip": "1.0.0",
"ext-gd": "1.0.0"
}
}
}
- 必须写完整版本号，如
"php": "8.1.0"，不能写"^8.1"或"8.1"—— Composer 不支持范围语法 - 只声明项目真正强依赖的扩展；不常用的扩展可不写，避免无谓限制
- PHP 版本建议选团队最低共识版，而非最高版；升级时先改这里，再跑
composer update --lock - 这个配置只影响
composer update时的求解逻辑，对composer install无副作用
--ignore-platform-reqs 不是替代方案，而是兜底开关
有人想绕过 platform 差异，直接加 --ignore-platform-reqs 跑 composer install。这能跳过校验，但治标不治本：
- 它不改变 lock 文件内容，只是让安装阶段“假装满足”——如果真缺
ext-gd，程序运行时照样报错 - CI 脚本里滥用它，等于把平台兼容性问题从构建阶段推迟到运行时，更难定位
- 它无法解决 lock 文件本身不一致的问题：两份因不同 PHP 版本生成的 lock，SHA256 不同，Git 提交历史就不可靠
真正要的不是“跳过检查”，而是“让所有人生成同一份 lock”。所以 config.platform 是规范起点，--ignore-platform-reqs 只应在离线部署或临时调试时谨慎使用。
为什么 config.platform 必须配合 --lock 使用？
PHP 版本升级后，光改 config.platform 并不够。Composer 不会自动重算依赖树——你得主动触发一次 composer update --lock（注意不是 composer update）。
-
--lock参数强制 Composer 仅更新 lock 文件中的 platform 字段，不改动任何包版本，也不重新解析依赖 - 等价于“刷新平台快照”，确保新
config.platform生效且不引入意外变更 - 执行后必须提交新的
composer.lock，否则别人composer install仍读旧 platform 声明 - 如果漏掉这步，团队里有人用了新 PHP，有人还在旧版，lock 文件就会持续分裂
平台一致性最难的不是写配置，而是让每次 config.platform 变更都伴随一次受控的 --lock 更新和 lock 提交——它不是开发者的自由操作，而是需要纳入 PR 检查流程的基础设施变更。
