我之前也踩过类似的坑，Rust默认的编译配置很容易在Docker的轻量镜像里出问题，结合你的情况，咱们一步步来排查解决：

1. 核心问题：Rust默认动态链接glibc #

Rust默认编译的二进制是动态链接glibc的，而你尝试的scratch、alpine（用musl libc）、busybox这类镜像要么没有glibc，要么用的是其他C标准库，自然会出现怪异的错误。而你测试的C++程序应该是静态编译或者适配了对应镜像的库，所以能正常运行。

2. 最靠谱的解决方案：强制静态编译（musl目标） #

直接编译出不依赖任何系统库的静态二进制，这是适配轻量Docker镜像的最佳方案：

步骤1：安装musl编译目标 #

在你的Arch Linux环境里执行：

rustup target add x86_64-unknown-linux-musl

步骤2：编译静态二进制 #

用musl目标编译你的Rust项目：

cargo build --release --target x86_64-unknown-linux-musl

编译后的二进制在target/x86_64-unknown-linux-musl/release/目录下。

步骤3：构建Docker镜像 #

比如用scratch镜像的Dockerfile：

FROM scratch
# 复制静态编译的二进制
COPY target/x86_64-unknown-linux-musl/release/your_binary_name /
# 运行程序
CMD ["/your_binary_name"]

构建并运行：

docker build -t rust-app .
docker run --rm rust-app

3. 处理依赖系统库的第三方Crate #

如果你的项目用到了像openssl这类依赖系统库的crate，默认可能还是会动态链接，需要在Cargo.toml里开启静态编译特性：

[dependencies]
# 以openssl为例，开启vendored特性静态编译依赖
openssl = { version = "0.10", features = ["vendored"] }

4. 排查其他可能的问题 #

• 检查二进制依赖：用ldd target/release/your_binary查看默认编译的二进制依赖，如果输出里有libc.so.6（glibc），那肯定不能在alpine里运行。静态编译的二进制用ldd查看会显示not a dynamic executable。
• 权限问题：如果二进制需要读写特定路径，在Dockerfile里要确保对应路径存在且有读写权限（scratch镜像几乎是空的，需要提前创建目录的话可以用多阶段构建先完成）。
• 多阶段构建优化：如果觉得本地安装musl麻烦，可以用多阶段构建在Docker里完成编译：

# 第一阶段：编译静态二进制
FROM rust:latest as builder
RUN rustup target add x86_64-unknown-linux-musl
WORKDIR /app
COPY . .
RUN cargo build --release --target x86_64-unknown-linux-musl

# 第二阶段：构建最终镜像
FROM scratch
COPY --from=builder /app/target/x86_64-unknown-linux-musl/release/your_binary_name /
CMD ["/your_binary_name"]

5. 备选方案：用glibc-based镜像运行 #

如果不想静态编译，也可以用debian、ubuntu这类基于glibc的镜像来运行你的默认二进制，比如Dockerfile：

FROM debian:stable-slim
COPY target/release/your_binary_name /
CMD ["/your_binary_name"]

这种方式更简单，但镜像体积会大一些。

按照上面的步骤试一下，应该能解决你遇到的问题。

内容的提问来源于stack exchange，提问作者VP.