在 Docker 镜像构建中，基础镜像决定了应用的运行环境，也直接影响镜像体积、安全性、兼容性和后期维护成本。
很多开发者在追求轻量化时，首先会想到 Alpine。但实际上，scratch、Distroless、Alpine 和 Debian Slim 分别代表了不同的设计思路，并不存在绝对最优的方案。
选择基础镜像的核心，不是单纯追求体积最小，而是在运行依赖、安全性和可维护性之间取得平衡。
一、scratch：极致精简
scratch 是 Docker 中最特殊的基础镜像，它本身不是一个 Linux 发行版，而是一个空镜像。
scratch 中没有 Shell、包管理器、动态库、CA 证书、时区数据库和常见系统工具。应用程序运行所需的文件，都需要明确放入镜像中。
对于 Go 服务，如果关闭 CGO 并生成完全静态链接的二进制文件，通常可以直接运行在 scratch 中。
它最大的优势是镜像体积和攻击面都非常小。镜像中没有多余的软件包，也没有 Shell、curl、wget 等工具，能够减少潜在安全风险。
但 scratch 的缺点同样明显。容器内部没有 Shell，出现问题时无法直接进入容器排查；如果程序依赖动态库、CA 证书或时区数据，也需要自行处理。
因此，scratch 最适合依赖明确、运行环境简单的静态编译程序，尤其是 Go 服务。
二、Distroless：只保留应用运行环境
Distroless 可以理解为 scratch 和传统 Linux 发行版之间的折中方案。
它的设计理念是，只保留应用程序运行所需要的运行时文件，不提供 Shell、包管理器和大量无关工具。
与 scratch 相比，Distroless 已经提供了一定的基础运行环境，因此兼容性更好，不需要开发者手动处理所有底层依赖。
同时，它仍然保持较小的镜像体积和较低的攻击面。由于没有 Shell 和常见系统工具，即使攻击者进入容器，也缺少大量可以直接利用的工具。
Distroless 的主要问题是排障仍然比较困难。由于没有 Shell，开发人员无法像使用普通 Linux 镜像一样进入容器进行排查。
因此，Distroless 更适合已经完成测试、运行依赖明确的生产环境服务。
三、Alpine：小而完整
Alpine 是目前最常见的轻量 Linux 基础镜像之一。
与 scratch 和 Distroless 不同，Alpine 提供了一个完整但精简的 Linux 用户空间。它拥有 Shell、BusyBox 和 apk 包管理器，因此开发、安装软件和故障排查都比较方便。
Alpine 的镜像体积较小，同时又保留了较好的使用便利性，因此非常适合作为通用轻量基础镜像。
不过，Alpine 最大的问题是使用 musl libc，而不是传统 Linux 发行版普遍使用的 glibc。
对于纯 Go 程序，这通常不会造成太大问题。但如果程序使用 CGO、依赖第三方二进制程序或复杂动态库，就可能出现兼容性问题。
因此，Alpine 的优势是轻量和方便，但不能因为它体积小，就默认适用于所有项目。
四、Debian Slim：兼容性与轻量化平衡
Debian Slim 是 Debian 的精简版本。
相比 Alpine，它通常更大，但使用 glibc，因此对传统 Linux 程序和第三方软件的兼容性更好。
Debian Slim 同时拥有成熟的软件生态和完善的包管理能力。出现问题时，可以安装调试工具，也更容易查找相关资料和解决方案。
对于运行依赖复杂的服务，Debian Slim 往往比 Alpine 更稳妥。
它并不是极致轻量方案，但在实际工程中，镜像多几十 MB 通常不是最重要的问题。相比之下，运行稳定性、兼容性和故障排查效率更值得关注。
因此，Debian Slim 可以看作是轻量化和工程兼容性之间比较稳妥的选择。
五、如何选择？
四种方案可以简单理解为不同层级的取舍。
- scratch 追求极致精简，适合完全静态编译、依赖简单的程序。
- Distroless 保留必要运行环境，同时移除大量无关工具，适合生产环境服务。
- Alpine 提供轻量但完整的 Linux 用户空间，适合需要 Shell、软件包管理和一定运行环境的项目。
- Debian Slim 则更强调兼容性和工程稳定性，适合依赖复杂或需要 glibc 环境的服务。
对于 Go 后端服务，我认为可以按照以下原则选择。
- 如果程序关闭 CGO，并且生成完全静态链接的二进制文件，可以优先使用 scratch。
- 如果希望保留一定运行环境，同时降低攻击面，可以选择 Distroless。
- 如果需要 Shell、软件包管理和方便的容器内排障，可以选择 Alpine。
- 如果服务依赖复杂，涉及 CGO、第三方二进制程序或 glibc 环境，则 Debian Slim 通常更加稳妥。
