Alpine 多阶段镜像构建成功，启动却报 libstdc++.so.6 不存在

Elixir/Erlang release 等程序在构建阶段正常生成，进入最终 Alpine 镜像后却报 Error loading shared library libstdc++.so.6、libgcc_s.so.1，并伴随 Error relocating。如果最终阶段只复制了应用发布目录，应先检查运行依赖，而不是继续重复编译。

这条处理路径适用于在 Alpine 环境构建、最终也使用兼容 Alpine 环境运行的动态链接程序。Debian 构建产物直接搬到 Alpine 时，还存在 glibc 与 musl 的兼容问题，补两个库不一定能够解决。

为什么构建阶段安装过仍然缺少

FROM alpine:… AS runtime 会建立一个新的阶段。之前在 builder 中安装的 build-base、编译器和库不会自动进入 runtime；COPY --from=builder /app/release /app 也只复制指定目录。

先查看 Dockerfile 的最后一个 FROM 以及其后的安装命令。若 libstdc++ 只在 builder 的依赖中，而报错的程序位于最终镜像，应把所需运行库安装到最终阶段。

以下是结构示例，BUILDER_IMAGE 和 RUNTIME_IMAGE 都必须替换为经过项目确认、发行版和架构相容的实际镜像：

FROM BUILDER_IMAGE AS builder
# 此处保留项目原有构建步骤，产物输出到 /app/release

FROM RUNTIME_IMAGE AS runtime
RUN apk add --no-cache libstdc++ libgcc
WORKDIR /app
COPY --from=builder /app/release/ /app/

RUNTIME_IMAGE 在本示例中必须是支持 apk 的 Alpine 镜像。不要照搬已经停止维护的旧 Alpine 标签，也不要为了补库先无差别执行 apk upgrade，这会扩大变更范围。

如果项目最终阶段已经切换为非 root 用户，安装命令应放在原有 USER 指令之前；随后仍恢复项目的非 root 运行方式。程序可能还依赖 OpenSSL、ncurses 或其他库，应按构建产物的实际需求保留，不能因本次只缺 C++ 库就删除原有依赖。

补库后仍报错，按日志区分

No such file or directory 指向缺少的具体库时，继续检查那个库在最终阶段的安装状态。若库已经存在，但错误变成某个版本符号不存在，检查 builder 与 runtime 的 Alpine 版本、库版本和架构；将构建与运行基础环境对齐，再重新构建全部发布产物。

如果日志指向不同的动态加载器路径，或构建用的是 glibc 系统、运行用的是 musl 系统，应优先使用与构建环境相容的运行镜像，或者在目标环境重新构建。不要从另一台机器随意复制 .so 文件：文件存在并不能保证 ABI、依赖链和加载路径正确。

验收要检查真正的最终镜像

新镜像启动后应不再出现库缺失或符号重定位错误，应用进程能持续运行，并通过项目原有的启动和健康检查。仅在 builder 阶段执行成功不算验收。

部署前保存旧镜像标签和部署配置。切换最终镜像会重建应用容器并可能中断请求，安排合适窗口；失败时恢复旧镜像，不删除数据库卷或其他持久数据。