phpEnv 不提供 intl 扩展，其可用性取决于当前切换的 PHP 版本是否编译时启用 --enable-intl 并正确链接 ICU 库；需先装 ICU 开发包，再通过 CONFIGURE_OPTS 指定 --with-icu-dir 重装 PHP，并验证 INTL_ICU_VERSION 输出及 Collator 类实例化。
phpEnv 本身不提供 intl 扩展，它只是 PHP 版本管理工具 —— intl 是否可用，完全取决于你当前 phpenv 切换的 PHP 版本是否已编译支持 intl，以及 ICU 依赖是否就位。直接装 phpEnv 不会自动解决 intl 缺失问题。
phpenv install 时没带 intl？补编译最可靠
phpenv 安装 PHP 时默认不启用 intl，因为 ICU 路径不确定、系统库版本不一，容易编译失败。你不能靠“装完再启 extension”来补救 —— 没编译进内核的 intl，extension=intl 会静默忽略或报 Invalid library (maybe not a PHP library)。
- 先确认系统已装 ICU 开发包：
brew install icu4c（macOS）、sudo apt install libicu-dev（Ubuntu）或sudo dnf install libicu-devel（RHEL/CentOS） - 查 ICU 安装路径：
brew --prefix icu4c或icu-config --prefix - 用 phpenv 重装目标版本，显式传 ICU 路径：
CONFIGURE_OPTS="--enable-intl --with-icu-dir=$(brew --prefix icu4c)" phpenv install 8.3.6 - 装完立刻验证：
phpenv shell 8.3.6 && php -r "echo INTL_ICU_VERSION;"—— 有输出才是真成功
phpenv + Homebrew macOS 下 intl 启用失败的典型表现
即使 phpenv 编译时加了 --enable-intl，macOS 上仍常因 ICU 动态链接失败而让 Collator 类不可用，错误如 Class 'Collator' not found 或 php --ri intl 显示 ICU version 为空。
- Homebrew 的
icu4c默认不软链到/usr/local/lib，PHP 运行时找不到libicuuc.dylib等文件 - 临时修复：运行
export DYLD_LIBRARY_PATH="$(brew --prefix icu4c)/lib:$DYLD_LIBRARY_PATH"（仅当前 shell 有效） - 永久修复：在
~/.zshrc或~/.bash_profile中添加该 export，并确保 phpenv 的 shims 被加载后生效 - 更干净的做法：用
brew install php@8.3替代 phpenv，它默认启用 intl 且已处理好 dylib 路径
phpenv 切换版本后 intl 消失？检查实际加载的 php.ini
phpenv 通过 shims 控制 PHP 二进制路径，但它不接管 php.ini 加载逻辑 —— 你改的可能是全局 php.ini，而 phpenv 实际用的是它自己生成的配置或系统默认路径。
立即学习“PHP免费学习笔记（深入）”；
- 执行
php --ini，看Loaded Configuration File是哪个路径，别只改/etc/php.ini - phpenv 安装的 PHP 通常把 ini 放在
$(phpenv root)/versions/8.3.6/etc/php.ini，直接编辑这个文件才有效 - 确认该 php.ini 中有
extension=intl（不是extension=php_intl.dll，那是 Windows） - 如果该文件里没有
extension_dir，补上：extension_dir = "$(phpenv root)/versions/8.3.6/lib/php/extensions/no-debug-non-zts-20230831"（目录名随 PHP 版本 ABI 变化）
intl 最难缠的从来不是“怎么开”，而是 ICU 版本与 PHP 编译绑定版本不一致 —— 差一个 patch 版本（比如 ICU 73.2 vs 73.1），NumberFormatter 就可能返回空字符串，且无任何报错。别信“装了就行”，每次换 PHP 或 ICU 都得重新验证 INTL_ICU_VERSION 和基础类实例化。
