Composer怎么锁定PHP版本_Composer config platform设置【锁定】

composer config platform.php 未生效是因为它仅在依赖解析阶段模拟 php 版本，不改变运行时真实环境校验；需配合删除 vendor/ 和 composer.lock 并在目标环境同步配置。

composer config platform.php 为什么没生效

因为 platform 只在本地安装/更新时起作用，它不会覆盖你当前 PHP 环境的实际版本检查逻辑；更关键的是，它只影响依赖解析阶段的“可用扩展+PHP 版本”模拟，不改变 composer install 运行时对真实环境的校验。

常见错误现象：composer install 报错 Your requirements could not be resolved，但你明明设了 platform.php，却还是提示某个包需要 PHP 8.2，而你本地是 8.1 —— 这说明依赖树里存在硬性版本约束（比如 "php": "^8.2" 在某个依赖的 composer.json 中），platform 无法绕过这种声明。

• 必须在项目根目录执行 composer config platform.php "8.1.0"（字符串格式，不能写 8.1）
• 该设置只写入当前项目的 composer.json 的 config.platform 字段，不会影响全局或其他项目
• 执行后记得删掉 vendor/ 和 composer.lock，再跑一次 composer install，否则旧 lock 文件会沿用之前的解析结果
• 如果用了 docker 或 CI 环境，确保该配置也存在于目标环境的 composer.json 中，而不是只在你本地配了

platform.php 和 platform.ext-xxx 的区别在哪

platform.php 告诉 Composer：“我假装运行的是这个 PHP 版本”，用于解决依赖要求高版本 PHP、但你暂时没法升级的场景；而 platform.ext-xxx（如 platform.ext-mbstring）是告诉 Composer：“我假装已安装这些扩展”，常用于 CI 环境缺少某些扩展但又不想装全量 PHP 的情况。

二者都属于“模拟平台能力”，但作用对象不同：一个是语言版本，一个是扩展存在性。它们一起用时，Composer 才会认为“这个 PHP 版本 + 这些扩展”是可用组合。

立即学习“PHP免费学习笔记（深入）”；

• platform.ext-mbstring 设为 true 或 false，不是版本号
• 若某包同时要求 php: ^8.2 和 ext-intl，你只设 platform.php 不设 platform.ext-intl，依然可能失败
• 注意大小写：ext-intl 正确，ext-Intl 无效

CI 中锁定 PHP 版本最可靠的做法

在 github Actions / gitlab CI 等场景下，光靠 platform 是脆弱的 —— 因为 Composer 仍会在安装前检查真实 PHP 版本是否满足 root package 的 require.php。真正要“锁定”，得从源头控制：让 CI 使用指定 PHP 镜像，并显式约束项目 composer.json 的 require.php 字段。

• CI 脚本里用 php -v 确认实际版本，别只信 platform
• 项目 composer.json 的 require.php 应写死为期望值，例如 "^8.1.0"，而不是 "^8.1"（后者在 8.1.x 更新时可能意外拉入不兼容变更）
• 如果用 composer update 生成 lock 文件，务必在和部署环境一致的 PHP 版本下操作，否则 lock 里记录的 dist URLs 可能对应错误 PHP 兼容性标签
• 可加一步验证：composer check-platform-reqs 能列出当前环境缺失的 platform 要求，适合放进 CI 检查环节

platform 设置后 composer install 还报 ext 错误？

因为 platform.ext-xxx 只影响依赖解析，不影响运行时加载。比如你设了 platform.ext-redis，Composer 就允许装需要 redis 扩展的包，但如果你实际没装 redis.so，php artisan serve 或 php index.php 运行时仍会报 class 'Redis' not found。

• platform 是编译期欺骗，不是运行期补丁
• Docker 用户容易忽略：PHP CLI 和 FPM 容器可能用不同镜像，platform 配置只解决 Composer 安装问题，不解决 apache/nginx 下 PHP 解释器缺扩展的问题
• 用 php -m | grep redis 直接检查扩展是否真实可用，比看 composer.json 更可靠
• 某些扩展（如 ext-sodium）在 PHP 7.2+ 是内置的，但 windows 下可能仍需手动启用，platform 无法掩盖这类系统级差异

事情说清了就结束。真正卡住的往往不是怎么配 platform，而是没意识到它只管“装得上”，不管“跑得了”。