应使用 exec.Command 调用 docker CLI 启动容器，禁用挂载与特权模式，通过 docker create/cp/start 传入代码，避免直连 Docker daemon 或 stdin 不稳定问题，并按语言选用预装运行时的 Alpine 镜像，配合 --pids-limit 等强化隔离。
如何用 Go 启动 Docker 容器执行用户代码
Go 本身不直接运行代码，得靠调用 docker run 命令启动隔离容器。关键不是“怎么写 HTTP 接口”，而是“怎么安全、可控地把用户代码喂进容器并拿到结果”。
- 必须用
exec.Command调用dockerCLI，别试图用github.com/docker/dockerSDK——它需要直连 Docker daemon（/var/run/docker.sock），在非 root 或容器化部署时权限和路径都容易出错 - 命令行参数要显式指定：禁止挂载宿主目录（
-v）、禁止特权模式（--privileged）、必须加--rm和超时（--memory=64m --cpus=0.5 --network=none） - 用户代码不能直接写进
docker run -i标准输入——某些镜像（如golang:alpine）的go run -对 stdin 处理不稳定；更稳的方式是先docker create，再docker cp传文件，最后docker start
为什么不能用 http.DefaultClient 调用 Docker API
很多人想绕过 CLI，直接 POST 到 http://localhost:2375/containers/create。这条路在开发机上看似能跑，上线就崩。
- Docker daemon 默认不监听 TCP（
DOCKER_HOST环境变量为空），启用需改 systemd 配置，生产环境几乎没人开——等于主动暴露攻击面 - Go 的
http.Client发请求时无法继承宿主的 Unix socket 权限，而dockerCLI 是通过/var/run/docker.sock（socket 文件）通信的，权限由文件系统控制 - 错误信息会变成
dial unix /var/run/docker.sock: connect: permission denied或client version 1.43 is too new（客户端 API 版本不匹配），但根本原因不是代码写错，是通信通道没对齐
docker run 的镜像选择与冷启动延迟
选镜像不是越小越好，得看语言运行时是否预装、是否带编译器。比如 golang:slim 有 go 命令但没 gcc，用户提交 C 代码就会报 exec: "gcc": executable file not found in $PATH。
- 建议按语言分镜像：C 用
gcc:alpine，Python 用python:3.11-slim，Go 用golang:1.22-alpine——alpine 小且默认禁用systemd，减少干扰 - 首次拉取镜像会卡住 HTTP 请求（冷启动），必须设超时：
cmd := exec.Command("docker", "pull", "golang:1.22-alpine")单独跑，成功后再进run流程；否则用户等 20 秒只看到504 Gateway Timeout - 别复用同一镜像 tag（如
latest）——上游更新可能破坏 ABI，某天 Python 用户突然发现numpy导入失败，实际是基础镜像里删了libgfortran
怎么防止用户代码逃出容器或打爆资源
光靠 --memory 和 --cpus 不够。Docker 的资源限制在内核层，但用户代码仍可能触发 OOM Killer、创建大量进程、或用 fork() 搞死 PID namespace。
立即学习“go语言免费学习笔记（深入）”；
- 必须加
--pids-limit=32，否则 Go 的for i := 0; i 会瞬间起几万个 goroutine，对应几百个线程，超出默认 PID 限额直接被 kernel 杀掉整个容器 - 禁止
--cap-add=ALL，也别加--security-opt seccomp=unconfined；用默认 seccomp profile 即可，它已禁掉mount、ptrace、reboot等危险 syscall - 输出截断必须在 Go 侧做：
io.CopyN(outWriter, containerOutput, 1024*1024)，而不是依赖docker run --log-driver=json-file --log-opt max-size=1m——日志驱动只管 daemon 日志，不管容器 stdout 实时流
最麻烦的其实是信号传递：用户代码里写 os.Interrupt 或 syscall.SIGTERM，你得确保 docker stop 发的信号真能透进去，而不是被 shell 层吃掉。这点很容易被忽略，一跑长时间循环就 kill 不掉。
