platform配置未生效是因为它仅在composer install/update时影响依赖解析，不修改已锁入composer.lock的版本；需删除composer.lock后重装并确保配置在根层级、格式正确。
platform配置为什么没生效？
因为platform只在composer install或composer update时起作用，且仅影响依赖解析阶段——它不会修改已锁入composer.lock的包版本，也不会绕过扩展检测。常见现象是：本地开发环境装了ext-redis，但生产环境没有，你加了"platform": {"ext-redis": "0.0.0"}后仍报错ext-redis is missing，大概率是composer.lock里还存着依赖ext-redis的真实版本约束。
实操建议：
- 删掉
composer.lock再运行composer install（确保从头解析） - 确认
platform写在composer.json根层级，不是config下 - 值必须是合法版本号格式（如
"7.4.0"、"0.0.0"），不能写false或null
如何让Composer假装某个扩展不存在？
用"platform": {"ext-xxx": "0.0.0"}是最直接的方式。Composer会把0.0.0当作一个“永远不满足”的版本，从而排除所有声明ext-xxx为必需依赖的包（比如phpunit/phpunit要求ext-dom，设"ext-dom": "0.0.0"后它就不再被选中）。
注意点：
- 只能伪造扩展（
ext-*）和PHP版本（php），不能伪造lib-*或自定义扩展名 -
"php": "8.1.0"会影响所有php版本约束，包括^8.1、>=8.0等，别误设成低于项目实际版本 - 某些包用
ext-*做软依赖（suggest而非require），这种不会被platform屏蔽
platform和config.platform-check的区别
config.platform-check控制是否检查当前环境是否满足platform声明的“最低要求”，默认true。设为false后，Composer不再报Your requirements could not be resolved这类错误，但它不会帮你跳过依赖——只是静默忽略不匹配。
典型误用场景：
- 想跳过
ext-gd检查，却只关了platform-check，结果composer install仍失败（因为依赖树里真有需要ext-gd的包） - 同时设
"platform": {"ext-gd": "0.0.0"}和"platform-check": false，后者其实多余——前者已足够排除 -
platform-check不影响install行为，只影响错误提示强度
CI/CD里怎么安全用platform？
在GitHub Actions或GitLab CI中，platform常用来模拟目标服务器环境（比如部署机只有PHP 8.0 + 无ext-memcached）。但容易踩的坑是：本地开发时没同步更新composer.json，导致CI跑的是旧platform配置，或composer.lock没提交。
关键动作：
- 把
platform配置纳入版本管理，不要只靠CI脚本临时覆盖 - CI中执行
composer install --no-interaction --prefer-dist前，确认composer.lock已提交且与composer.json一致 - 避免用
composer config platform.ext-xxx 0.0.0动态设置——它只改当前目录composer.json，CI容器重启即失效
真正麻烦的不是怎么写platform，而是它只在依赖解析那一刻起效；一旦composer.lock固化了某条路径，后续不管你怎么改platform，只要不重装，它就继续走老路。
