drone ci天然容器原生，所有steps必须运行在独立容器中，拒绝宿主机依赖；关键在于禁用docker.sock挂载、避免伪隔离配置、采用多阶段dockerfile实现零残留交付。
Drone CI 本身就是容器原生的 CI 引擎，不需要额外“部署为容器原生”——它从设计上就拒绝宿主机环境依赖，所有 steps 必须运行在独立容器中，天然满足「全生态隔离、无环境残留」的要求。关键在于配置是否真正遵循了这一前提。
为什么 drone-runner-docker 不等于「容器原生」
很多人以为只要用 drone-runner-docker 就算容器化了，其实不然。这个 runner 只是把 step 扔进 Docker 容器执行，但它默认会挂载宿主机的 /var/run/docker.sock，导致 step 内部能调用宿主机 Docker daemon —— 这直接破坏了隔离性，也埋下环境残留隐患（比如镜像没清理、容器没 stop）。
- 典型错误配置：
docker_socket: /var/run/docker.sock（出现在 runner 启动参数或docker-compose.yml中） - 后果：step 中执行
docker build或docker run时，实际操作的是宿主机 Docker，不是隔离容器 - 正确做法：禁用该挂载，改用
plugins/docker插件（它通过 API 调用远端 registry + 构建上下文打包方式，不依赖本地 socket）
.drone.yml 中必须避免的三类「伪隔离」写法
即便 runner 配置干净，.drone.yml 写错照样污染环境。以下写法看似简洁，实则绕过容器隔离机制：
- 使用
image: golang:1.21但commands中执行go install ./cmd/...→ 安装二进制到容器根文件系统，虽不残留宿主机，但违反「构建产物只输出、不安装」原则，增加镜像体积且不可复现 - 在
commands里写curl -sL https://git.io/getmicrolib | sh→ 动态下载脚本并执行，破坏构建环境确定性，且可能污染容器临时层 - 用
volume挂载宿主机路径（如/tmp/build-cache:/cache）→ 缓存跨构建共享，但若未清理或权限失控，会成为残留源
正确姿势：所有依赖通过 go mod download 显式拉取；缓存用 cache 块声明（Drone 自动管理）；二进制只写入 /tmp 或直接 docker build 构建最终镜像。
Golang 微服务构建中如何确保「零残留交付」
微服务场景下，交付物必须是纯净镜像，而非中间产物。常见陷阱是把 go build 出来的二进制直接当成品，忽略 Go 的交叉编译与多阶段构建能力：
- 错误：step 中
go build -o app .，然后用scp或rsync推到服务器 → 二进制绑定构建容器环境（CGO_ENABLED=1、libc 版本等），上线后可能 panic - 正确：用多阶段 Dockerfile，base 阶段用
golang:1.21构建，final 阶段用scratch或alpine:latest，仅 COPY 二进制 → 镜像体积小、无残留、可验证 - Drone 配合方式：用
plugins/docker插件，指定dockerfile: Dockerfile，不手写docker build命令
示例关键片段：
steps:
- name: build-and-push
image: plugins/docker
settings:
dockerfile: Dockerfile
tags: ${DRONE_TAG}
repo: your-registry.com/myservice
username: ${DOCKER_USERNAME}
password: ${DOCKER_PASSWORD}
注意：Dockerfile 必须是项目内真实文件，不能靠 commands 临时生成 —— 否则破坏声明式构建一致性。
真正难的不是让 Drone 跑起来，而是让每个 step 都严格遵守「容器即一次性沙盒」这条铁律。任何一步偷偷触碰宿主机、复用非声明式缓存、或产出非容器化交付物，都会让「全生态隔离」变成一句空话。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
