根本原因是运行时环境与安装环境不一致：--ignore-platform-reqs仅跳过安装校验，不解决php版本、扩展缺失或autoload映射错配问题；工具自身校验、polyfill条件加载失败、docker构建与运行环境差异等均会导致class not found。
忽略平台要求后还能报错，说明问题根本不在安装阶段的校验上——--ignore-platform-reqs只跳过“能不能装”，不解决“装完能不能跑”。真正出问题的地方，往往藏在运行时环境、自动加载或工具链自身校验里。
vendor/bin/xxx 执行时报 Class not found 或 PHP 版本不满足
很多命令行工具（如 phpunit、larastan、php-cs-fixer）在启动时会自己检查 PHP 版本或扩展，和 Composer 安装阶段完全无关。--ignore-platform-reqs对它们无效。
- 先确认报错来源：运行
vendor/bin/phpunit --version看是否直接失败；如果是，说明是该工具自身的启动校验 - 查工具包的
composer.json，看它的require里有没有写"php": "^8.2"—— 这类约束会在它自己的入口文件里被硬性检查 - 临时解法：降级工具版本（如改用
phpunit:^9而非^10），或加运行参数绕过（如phpunit --no-configuration） - 别指望
composer config platform.php能骗过这些工具——它们读的是真实PHP_VERSION
autoload.php 加载后报错：Class not found / Function undefined
这通常不是 Composer 没装对，而是 autoload 规则没覆盖到，或者因平台忽略导致装了错误版本的包（比如 PHP 8.2 下强行装了只兼容 7.4 的旧版 monolog）。
- 检查
vendor/composer/autoload_classmap.php是否包含你引用的类路径；没有？说明该包没声明autoload字段，或用了classmap但没运行dump-autoload - 强制重生成自动加载：
composer dump-autoload -o，比反复install更快定位问题 - 如果用了
psr-4映射，确认对应目录真实存在、拼写大小写一致、权限可读（尤其 Docker 挂载卷场景） - 某些 polyfill 包（如
symfony/polyfill-mbstring）依赖 ext-mbstring 是否启用——--ignore-platform-req=ext-mbstring跳过了安装检查，但 polyfill 内部的条件加载逻辑可能直接跳过注册，导致函数不可用
CI/CD 构建成功但运行时崩溃
典型症状：Docker build 阶段加了 --ignore-platform-reqs，镜像构建通过，一启动容器就 Fatal error: Uncaught Error: Call to undefined function mb_strlen()。
- 根本原因：build 阶段 PHP 环境有 ext-mbstring，runtime 镜像没装——
--ignore-platform-reqs不会帮你把扩展装进最终镜像 - 检查 runtime 镜像的
php -m输出，确认所有ext-*都真实启用；缺失的必须在Dockerfile的 runtime 阶段显式安装（如apt-get install php-mbstring） - 更稳妥的做法：在 build 阶段用
--platform声明目标环境（如composer install --platform=php:8.1.30 --platform=ext-mbstring:1），而不是盲目跳过 - 永远不要在 CI 脚本里无条件加
--ignore-platform-reqs：它掩盖了环境不一致，让问题延后到部署甚至上线才暴露
最容易被忽略的一点是：即使你设了 "platform": {"php": "8.3.0"}，若 Composer 版本太老（如 2.2.x），它可能无法正确解析新版 PHP 的语法特性，导致 autoload 映射漏掉关键类——这种问题不会在 install 报错，而是在第一次 new 实例时才崩。
