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，而是没意识到它只管“装得上”，不管“跑得了”。 
