go模块依赖无原生沙箱机制，所有import包均运行于宿主进程地址空间，vendor仅复制代码不隔离权限；真正安全需进程级隔离+syscall过滤或wasmer-go的wasm内存级隔离。
Go 模块依赖本身没有内置沙箱机制，所有 import 的包都直接运行在宿主进程地址空间里——这意味着一个恶意或有缺陷的依赖，能直接调用 os.RemoveAll、net.Listen 或篡改全局变量。所谓“模块依赖安全沙箱”，不是 Go 语言原生能力，而是必须由开发者主动构建的隔离层。
为什么 go mod vendor 不能当沙箱用
go mod vendor 只是把依赖复制到本地目录，并不改变其执行权限或内存边界。vendor 后的代码依然享有和主程序完全相同的系统调用能力、文件读写权限和网络访问能力。
- 它不阻止
os/exec.Command("rm", "-rf", "/")执行 - 它不拦截
http.DefaultClient.Do发出的任意 HTTP 请求 - 它不隔离
sync.Map或全局var的跨包共享
vendor 是构建确定性、可复现依赖的手段，不是安全控制手段。
真正可行的沙箱：进程级隔离 + syscall 过滤
要限制第三方模块行为，唯一可靠的方式是将其运行在独立进程中，并通过 Linux namespace 或 seccomp 进行系统调用过滤。Go 自身不提供这类能力，需借助外部工具或封装 syscall。
- 使用
gvisor或firejail启动子进程，限制其能访问的 syscalls（例如禁用openat、connect） - 在 Go 中用
exec.CommandContext启动子进程，并设置syscall.SysProcAttr的Cloneflags（如unix.CLONE_NEWPID | unix.CLONE_NEWNET） - 避免用
plugin包加载依赖——它共享主进程地址空间，且已被官方标记为“实验性、不推荐用于生产”
注意：unsafe 包一旦被依赖引入，沙箱即失效；任何含 //go:linkname 或反射修改未导出字段的代码，都可能绕过所有隔离。
替代方案：wasm 沙箱 + wasmer-go
若第三方模块支持编译为 WebAssembly（比如用 TinyGo 写的工具库），可将其作为 wasm 模块加载进 wasmer-go 运行时。这是目前 Go 生态中唯一能实现内存级隔离的方案。
-
wasmer.NewMemory创建的内存是严格受控的线性内存，无法越界访问宿主 Go 堆 - 所有 I/O 必须显式通过导入函数（import function）暴露，例如只允许传入预定义的
read_file而非完整os包 - 需提前将依赖编译为
.wasm文件，不能直接 import Go 模块源码
这个路径适合规则引擎、表达式求值等计算密集但 I/O 受限的场景；对需要调用 net/http 或 database/sql 的模块不适用。
最容易被忽略的漏洞点：init 函数与全局副作用
哪怕你把模块放进子进程或 wasm，只要它包含 func init()，就可能在加载时触发不可控行为——比如注册全局 http handler、启动 goroutine、修改 http.DefaultTransport。
这类副作用发生在模块导入阶段，早于你任何沙箱逻辑的介入时机。目前没有编译期或运行时机制能安全地“跳过”某个模块的 init。唯一办法是 fork 并 patch 源码，移除危险初始化逻辑，再重新编译。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
