不能直接用go run执行用户代码，因其复用宿主gopath、gocache和goroot，启用cgo，且易被//go:linkname或import "c"绕过限制，导致全局状态污染和安全风险。
直接用 go run 或复用宿主 GOPATH 运行用户提交的 Go 代码，等于把编译器和模块缓存全权交给不可信输入——这是高危行为，必须禁用。
为什么不能用 go run 执行用户代码
go run 会复用宿主的 GOPATH、GOROOT 和模块缓存（$GOCACHE），且默认启用 cgo；恶意代码可通过 //go:linkname 绕过符号限制，或通过 import "C" 加载任意本地库，甚至篡改编译器行为。更严重的是，它不隔离构建过程——一个 init 函数就能污染全局状态或提前 panic 整个服务进程。
- 禁止在沙箱内调用
go run，哪怕加了-mod=readonly也不安全 - 不要依赖
go list -deps提前扫描——它不校验实际编译时的 import 路径解析结果 - 用户
.go文件若含replace指令或go:build条件编译，可能绕过白名单检查
CGO_ENABLED=0 go build 是唯一可信赖的编译方式
要生成真正静态、无外部依赖、可跨镜像运行的二进制，必须显式关闭 cgo。仅设 GOOS/GOARCH 不起作用，因为 Linux 下 cgo 默认开启，且 net、os/user 等标准包会隐式触发 cgo 依赖。
- 执行命令必须为：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o /tmp/task.bin -ldflags="-s -w" main.go - 若代码中出现
import "C"或调用net.LookupHost，编译会直接失败——这是好事，说明你及时拦截了非纯 Go 依赖 - 验证是否成功：运行
ldd /tmp/task.bin，输出必须是not a dynamic executable，而非列出一堆libc.so - 别在 macOS 宿主机上交叉编译后就认为“已隔离”——Linux 内核 syscall number 差异可能导致 panic，真机或 QEMU 测试不可跳过
启动时必须绑定三重隔离参数
编译完只是第一步，执行阶段仍需切断与宿主的连接点。关键不是“能不能跑”，而是“跑坏了能不能关住”。
-
cmd.Dir必须指向全新os.MkdirTemp("", "run-*")目录，且该目录父级不可遍历（禁止../） -
cmd.Env必须显式覆盖，至少包含PATH=/usr/bin:/bin；严禁使用os.Environ()或留空 -
cmd.SysProcAttr需设置：Credential: &syscall.Credential{Uid: 65534, Gid: 65534}（nobody 用户），Linux 下还可加Chroot，macOS 则靠Credential+Dir组合兜底 -
cmd.Stdin/cmd.Stdout/cmd.Stderr必须重定向到bytes.Buffer或独立文件，否则日志混入主进程输出，破坏可观测性
超时与资源限制不能只靠 context
exec.CommandContext 的 timeout 只杀进程树根，但子进程可能 fork 出孙子进程逃逸；且它不控制内存、CPU 或文件描述符用量。Linux 下必须补上 syscall.Setrlimit，macOS 则受限更多。
- Linux：在
cmd.SysProcAttr中设置RlimitAs（虚拟内存）、RlimitCPU（秒级 CPU 时间）、RlimitFsize（输出文件大小上限） - macOS：无法直接设 rlimit，需配合
launchctl limit预设，或改用cgroup v2（需 root） - 永远用
cmd.Wait()或cmd.Run()，别用cmd.Start()+ 手动Wait——这会漏掉 context cancel 的自动清理 - 超时后检查
cmd.ProcessState.ExitCode()是否为 -1（信号终止），而非只看 error 是否为context.DeadlineExceeded
最易被忽略的是：编译和执行必须在不同用户下完成。用 root 编译再降权执行，等于把 /tmp 目录权限和模块缓存暴露给 nobody——应全程以低权限用户操作，连 go build 命令也要在 sandbox 用户上下文中执行。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
