应确认 composer diagnose 显示的 PHP binary 路径，用该路径执行 php --ini 和 php -m 验证实际加载的配置与扩展，针对对应版本的 CLI php.ini 或 conf.d 目录启用扩展，并检查 ICU 等依赖版本一致性。
composer diagnose 显示 PHP binary 路径和你预期不一致怎么办
Composer 默认调用系统 PATH 中第一个 php，但你可能装了多个 PHP 版本（比如 Homebrew 的 php@8.2 和系统自带的 php），或者 Docker 容器里用了独立镜像。运行 composer diagnose 时看到的 PHP binary 路径（如 /opt/homebrew/bin/php）才是它真正依赖的环境，不是你 which php 看到的，更不是浏览器里 phpinfo() 显示的那个。
常见错误现象：你在 /usr/local/etc/php/8.2/php.ini 里启用了 extension=intl，但 composer diagnose 报告 PHP binary: /opt/homebrew/bin/php，而这个路径对应的配置文件其实是 /opt/homebrew/etc/php/8.2/php.ini —— 改错文件就永远不生效。
- 先执行
composer diagnose，抄下PHP binary那一行的完整路径 - 用该路径直接跑：
/opt/homebrew/bin/php --ini，确认Loaded Configuration File是哪个 - 再跑
/opt/homebrew/bin/php -m | grep intl，验证扩展是否真在该 PHP 实例中加载 - 别碰 Apache/Nginx 的
php.ini，除非你明确在 Web SAPI 下跑 Composer（极少见）
Ubuntu/Debian 上装了 php8.2-intl 还报 ext-intl 缺失
包名必须严格匹配当前 CLI PHP 版本，且 apt install 只是安装文件，不等于自动启用。Ubuntu 22.04+ 默认会为 CLI 自动写 /etc/php/8.2/cli/conf.d/20-intl.ini，但旧版本或手动切换过 PHP 版本后，这步可能被跳过。
典型表现是 php -m | grep intl 没输出，php --ini 显示 CLI 加载了 /etc/php/8.2/cli/php.ini，但里面没 extension=intl，也没包含 conf.d/ 目录。
立即学习“PHP免费学习笔记（深入）”；
- 确认 PHP 版本：
php -v输出是PHP 8.2.x，就只能装php8.2-intl，不能只装php-intl - 装完检查：
ls /etc/php/8.2/cli/conf.d/*intl*.ini，如果不存在，手动创建/etc/php/8.2/cli/conf.d/20-intl.ini，内容只有一行：extension=intl - 别改
/etc/php/8.2/cli/php.ini主文件——它通常已包含include(/etc/php/8.2/cli/conf.d/*.ini)，优先走 conf.d - 验证：
php -r "new \IntlDateFormatter();"，能执行不报错才算真可用（比php -m更可靠）
Docker 构建时 composer install 报 ext-pcntl 缺失
ext-pcntl 在 Alpine 或最小化镜像里默认不可用，且它根本不能在 Windows/macOS 上启用——但 Composer 仍会校验，因为 composer.lock 是在完整 Linux 环境生成的。这不是要你硬装 pcntl，而是告诉 Composer：“我知道它缺，但我项目运行时不依赖它”。
错误信息通常是：Your platform does not meet the minimum requirements: ext-pcntl is missing。这时候强行 RUN apk add php82-pcntl 不仅无效（Alpine 的 php82-pcntl 包实际不提供 pcntl），还会让镜像变臃肿。
- 优先用
config.platform虚拟声明：在项目根目录composer.json里加："config": { "platform": { "ext-pcntl": "1.0.0", "ext-posix": "1.0.0" } } - 这个配置可提交、可复现，不影响运行时兼容性判断，只绕过安装前的平台校验
- 不要用
--ignore-platform-reqs：它跳过所有检查，包括 PHP 版本，CI 环境容易埋雷 - 如果项目真用到了
pcntl（比如队列监听），那镜像必须用完整版 PHP 基础镜像（如php:8.2-cli），而不是php:8.2-cli-alpine
macOS Homebrew PHP 启用了 ext-intl 但 composer 仍报错
Homebrew 安装的 PHP 默认不带 intl，即使你 brew install php@8.2，也得额外 brew install php@8.2-intl，而且它不会自动往 php.ini 里加 extension="intl" —— 这步必须手动补。
更隐蔽的问题是 ICU 版本不兼容：Homebrew 更新了 icu4c（比如升到 74.x），但 PHP 是用旧 ICU（比如 72.x）编译的，导致 intl 扩展虽能加载，却在 Composer 校验时静默失败。
- 先查 PHP 实际用的 ICU 版本：
php -r "echo INTL_ICU_VERSION;" - 再查系统 ICU 版本：
icu-config --version或pkg-config --modversion icu-i18n - 如果两者主版本号不一致（如 PHP 说 72，系统说 74），重装 PHP：
brew reinstall php@8.2 - 装完检查
/opt/homebrew/etc/php/8.2/php.ini（M1/M2）或/usr/local/etc/php/8.2/php.ini（Intel），确保有extension="intl"且未被注释 - 验证：
php -i | grep "ICU version"，输出应和php -r "echo INTL_ICU_VERSION;"一致
php -m 有输出当成“扩展已可用”——很多扩展（尤其是 intl、zip、gd）加载成功但功能异常，Composer 会在内部调用构造函数或常量做二次校验，这时光看模块列表毫无意义。 
