我有一个 src/BUILD.bazel 文件（在 MacOs 上）：
load("@io_bazel_rules_docker//go:image.bzl", "go_image")
load("@io_bazel_rules_go//go:def.bzl", "go_binary", "go_library")
load("@io_bazel_rules_docker//container:container.bzl", "container_image")
go_image(
name = "bazel_docker_image",
srcs = ["main.go"],
pure = "on",
)
以下方案可使工作无误：
bazel build //src:bazel_docker_image
显示：
INFO: Analyzed target //src:bazel_docker_image (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //src:bazel_docker_image up-to-date:
bazel-bin/src/bazel_docker_image-layer.tar
INFO: Elapsed time: 2.361s, Critical Path: 0.03s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
但是tar文件（可以作为镜像导入到docker中）仅包含静态链接的任务。该镜像无法作为容器运行，因为它不包含其他内容。
/usr/lib/libSystem.B.dylib
那么，@go_image_base//image有什么意义呢？我认为它应该生成一个包含所有必需库、有效入口点等的基本完整独立映像。
如果查看bazel-bin/external/go_image_static/image/000.tar.gz.nogz，会发现Bazel似乎生成了一个完整的映像，更接近于Bazel文档所建议的输出。这是怎么回事？
此外，Bazel文档还提到：
To address this, we publish variants of the distroless runtime images
tagged :debug, which are the exact-same images, but with additions
such as busybox to make debugging easier.
但是没有提供示例。
这时候，我最好从alpine制作一个容器镜像，并自己完成所有操作。总的来说，我真的希望能解决这个问题，因为Bazel通常会让这种Docker操作变得更加简单。