composer在alpine上失败主因是php扩展未启用，非musl兼容问题；应显式启用json/xml/mbstring/zip等扩展，并用官方脚本安装而非apk，避免glibc误装。
直接结论：Composer 本身不依赖 glibc，它在 Alpine 上跑不起来，99% 是因为 PHP 扩展缺失或未启用，不是 musl 兼容问题。强行装 glibc 是误诊，反而引入新故障。
为什么 composer --version 报 undefined function json_encode()？
这不是 musl 的锅，是 Alpine 的 PHP 镜像默认不启用 json、xml、mbstring 这些 Composer 必需的扩展——它们虽然已预装（apk add php83-json 等），但没被 docker-php-ext-enable 激活。
- 运行
php -m | grep json，如果无输出，说明扩展没启用 - 别信
apk list | grep php-json显示已安装就完事 - 必须显式执行：
docker-php-ext-enable json xml mbstring zip - 改完要重启 PHP CLI 或重建容器，
php -v不报错才代表生效
为什么用 apk add composer 在 Alpine 3.16+ 会失败？
Alpine 官方早在 3.16 就移除了 composer 包，不是兼容问题，是维护策略变更：他们认为 Composer 是应用级工具，不该由系统包管理器分发。
- 直接运行
apk add composer会报ERROR: unable to select packages - 正确做法是用官方安装脚本：
curl -sS https://getcomposer.org/installer | php - 务必先装好依赖：
apk add --no-cache curl unzip git，否则 installer 会卡在解压或 Git clone - 安装后移入 PATH 并设可执行位：
mv composer.phar /usr/local/bin/composer && chmod +x /usr/local/bin/composer
为什么装了 glibc 还是报 GLIBC_2.30 not found？
你正在给错误的对象打补丁。Composer 是纯 PHP 脚本（phar），不链接任何 C 库；报这个错的通常是你的项目依赖的二进制扩展（如 sqlsrv、grpc）或第三方 CLI 工具（如 protoc、pnpm），不是 Composer 本身。
- 先确认出错命令是谁：
composer install报错？还是vendor/bin/sail启动时崩溃？ - 如果是
composer install卡在某个扩展安装环节，检查那个扩展是否为 glibc 编译（ldd vendor/ext/xxx.so | grep libc.so） - 强行装
glibc前，优先尝试源码编译：pecl install sqlsrv（需先apk add unixodbc-dev autoconf g++） - 若必须用预编译二进制，再考虑
GLIBC_VERSION=2.37-r0+LD_LIBRARY_PATH=/usr/glibc-compat/lib，但得同步补libstdc++和静态版依赖库（如postgresql-client-static）
多阶段构建中如何避免 musl/glibc 混乱？
最容易被忽略的是：glibc 只装在 builder 阶段，却没复制到 final 阶段；或者 final 镜像里混进了 musl 和 glibc 两套 libc，导致 ldd 行为异常、php 启动失败。
- builder 阶段装 glibc 后，必须显式
COPY --from=builder /usr/glibc-compat /usr/glibc-compat - final 阶段的
LD_LIBRARY_PATH要严格限定，不要写成/usr/lib:/usr/glibc-compat/lib，应只留后者 - 最终镜像里运行
ldd $(which php)，输出中不应出现libc.so.6 => /lib/musl-libc.so.1和/usr/glibc-compat/lib/libc.so.6并存 - 更稳的做法：builder 用
php:8.3-cli-slim（glibc），final 用php:8.3-alpine（musl），中间只拷vendor/和代码，彻底隔离 libc 环境
