在 Ubuntu Docker 环境中通过 apt 安装 PHP 8.0 及扩展后，Apache 下模块正常加载，但 CLI（php -v/php -m）却缺失 mbstring 等扩展——根本原因是系统默认将 php 命令指向了未安装扩展的 PHP 8.1 CLI 版本，导致配置与扩展路径错配。
在 ubuntu docker 环境中通过 apt 安装 php 8.0 及扩展后，apache 下模块正常加载，但 cli（`php -v`/`php -m`）却缺失 `mbstring` 等扩展——根本原因是系统默认将 `php` 命令指向了未安装扩展的 php 8.1 cli 版本，导致配置与扩展路径错配。
当在 Ubuntu 18.04（或更新版本如 20.04/22.04）中使用 apt-get install php8.0-* 安装扩展时，APT 会为每个 PHP 版本（如 php8.0、php8.1）分别安装独立的 CLI 和 Apache SAPI 配置目录：
- CLI 配置：/etc/php/8.0/cli/
- Apache2 配置：/etc/php/8.0/apache2/
但关键陷阱在于：php 命令本身是一个由 update-alternatives 管理的符号链接。即使你只显式安装了 php8.0-* 包，系统仍可能因依赖关系（例如某些 php-common 或 php-cli 元包升级）自动拉入 php8.1-cli，并将其设为 php 命令的默认目标——这正是 php -i 显示 /etc/php/8.1/cli/php.ini 的原因。
此时，你安装的所有 php8.0-* 扩展仅注册在 /etc/php/8.0/cli/conf.d/ 下，而 php 命令实际运行的是 PHP 8.1 解释器，自然无法加载 8.0 的 .ini 文件和扩展，从而报出 Call to undefined function mb_internal_encoding() 等致命错误。
✅ 正确且“干净”的解决方案是：显式声明 CLI 默认版本，而非手动编辑 .ini 文件或硬链接：
立即学习“PHP免费学习笔记（深入）”；
# 安装 PHP 8.0 及所需扩展（注意：无需安装 php8.1）
RUN apt-get update && apt-get install -y \
php8.0 \
php8.0-curl php8.0-gd php8.0-gettext php8.0-gmp \
php8.0-iconv php8.0-imap php8.0-intl php8.0-mbstring \
php8.0-mysql php8.0-oauth php8.0-redis php8.0-xdebug \
php8.0-xml php8.0-yaml php8.0-zip \
libapache2-mod-php8.0 \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
# 关键一步：强制将 'php' 命令指向 php8.0 CLI
RUN update-alternatives --set php /usr/bin/php8.0⚠️ 注意事项：
- 必须在 apt-get install 之后执行 update-alternatives --set，否则 /usr/bin/php8.0 尚未注册；
- 若需验证效果，可在 Dockerfile 中追加调试命令：
RUN php -v && php -m | grep -E '^(mbstring|intl|curl)$' && php -i | grep "Configuration File"- 不推荐使用 ln -sf /usr/bin/php8.0 /usr/bin/php 替代 update-alternatives，因其绕过 APT 的替代系统，可能导致后续升级冲突；
- 若确实需要 PHP 8.1，应统一安装 php8.1-* 并设置对应 --set，避免混用版本。
该方案从机制层面修复了 CLI 与 Web SAPI 的版本割裂问题，确保 php 命令、php-config、phpize 及所有扩展配置严格对齐所选主版本，是 Docker 环境下可复现、可维护、符合 Debian/Ubuntu 包管理规范的最佳实践。
