go模块不提供运行时权限控制，仅管理依赖引入与校验；限制第三方包行为需依靠os层隔离（如capabilities、seccomp）、只读文件系统或网络策略，而非go mod机制。
Go 模块本身不提供运行时权限控制，所谓“限制第三方包在生产环境的权限”，本质是阻止其执行敏感操作（如读写文件、网络外连、执行命令），而非依赖管理层面的功能。
go mod 无法控制包的行为，只能控制它是否被引入
go.mod 和 go.sum 只负责声明和校验哪些代码被编译进二进制，不干预运行时行为。即使你用 replace 把某个包替换成空实现，只要原包代码里有 os.Open 或 net.Dial，它照样能调用——模块系统不会重写 AST 或注入沙箱。
- 依赖管理工具 ≠ 安全沙箱，Go 没有类似 Java SecurityManager 或 Python
venv + restrict imports的原生机制 -
go mod vendor只是把源码复制到本地，并不改变其执行能力 -
replace和exclude只影响构建阶段，对已编译的二进制无效
真正能起作用的是构建与运行时隔离手段
要限制第三方包的实际权限，得靠操作系统或容器层，不是 go mod 能解决的：
- Linux capabilities：启动时去掉
CAP_NET_RAW、CAP_SYS_ADMIN等，让包即使调用net.InterfaceAddrs()也直接失败 - seccomp：用 profile 拦截
openat、connect、execve等系统调用（Docker/Kubernetes 支持） - 文件系统只读挂载：把
/tmp、/etc、$HOME设为只读，让包无法写配置或缓存 - 网络策略：iptables 或 CNI 插件禁止 outbound 连接，除非明确放行特定域名/IP
开发阶段可做轻量级预防：用 vet + 静态分析拦截高危调用
虽然不能 runtime 限制，但可以在 CI 中提前发现风险点：
- 用
go vet -tags=production配合自定义 analyzer，扫描是否引用了os/exec、crypto/rand.Read（某些场景需审计）、net/http.DefaultClient等 - 借助
staticcheck或gosec检查硬编码 token、明文密码、不安全反序列化等 - 在
go.mod里用// indirect标记非直接依赖，再配合go list -deps -f '{{.ImportPath}}' ./... | grep -E '^(os/exec|net/http|syscall)'快速定位可疑导入
真正关键的不是“怎么在 go mod 里设权限”，而是接受一个事实：Go 的模块系统只管“代码从哪来、版本是否一致”，不管“代码能干什么”。越早把权限控制移到 infra 层（如 systemd service 文件里的 NoNewPrivileges=true），越不容易在上线后才发现某 SDK 悄悄连了外网。
