Trivy 扫描 Go 静态二进制需强制启用文件系统扫描、注入 go.mod.json 并避开挂载点；OOMKilled 根源是 cgroup v1 与 Go 内存统计错位；eBPF trace 断链因用户态与内核态上下文未桥接。

怎么用 Trivy 扫描 Go 二进制镜像不漏报 CVE？ Trivy 默认对 golang:alpine 这类基础镜像扫描很准，但对纯静态编译的 Go 二进制（比如用 CGO_ENABLED=0 go build 打出来的）容易跳过软件包层——它根本没写入 /var/lib/dpkg 或 /var/lib/rpm，Trivy 的 OS 包扫描器直接略过。

关键不是换工具，而是告诉 Trivy：「这镜像里其实有 Go 模块信息」。得强制启用 --scanners vuln,config,secret,filesystem，再加 --security-checks vuln,config,secret，重点是补上 --skip-dirs /proc,/sys,/dev 避免挂载点干扰。

• Go 二进制本身不含包管理元数据，必须靠 go list -json -m all 输出提前注入到镜像里（比如 COPY 到 /app/go.mod.json），再用 --input 指向它
• 别依赖 trivy image --light，它会关掉文件系统扫描，漏掉嵌入的第三方库（如 github.com/gorilla/mux 编译进 binary 的版本）
• Alpine 镜像 + musl libc 场景下，CVE 匹配要开 --ignore-unfixed，否则一堆 “no fixed version” 噪声掩盖真实风险

为什么 runtime.GC() 调用后容器突然被 OOMKilled？ Go 程序在容器里触发 runtime.GC() 本身不致命，但若同时满足三个条件：cgroup v1 + memory.limit_in_bytes 设得太紧 + GC 后堆碎片未及时归还给 OS，就会让 cgroup 认为进程“占着内存不放”，直接发 SIGKILL。

根本原因不是 GC，是 Go 1.19+ 默认开启的 GOZLIB=1 和 runtime.MemStats.Sys 统计偏差——它把 mmap 区域全算进 Sys，但 cgroup 只看 memory.usage_in_bytes。两者对“已用内存”的定义错位了。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 优先检查 cat /sys/fs/cgroup/memory/memory.usage_in_bytes 和 runtime.ReadMemStats 的 HeapSys 差值，差 200MB 以上大概率是 mmap 内存没被 cgroup 正确归类
• 临时缓解：启动时加 GODEBUG=madvdontneed=1，让 Go 在归还内存时用 MADV_DONTNEED 而非 MADV_FREE（后者在 cgroup v1 下不立即释放）
• 长期方案：升级到 cgroup v2 并设 memory.high 替代 memory.limit_in_bytes，v2 对 mmap 内存统计更准

用 opentelemetry-go 接入 eBPF 运行时审计时，trace 为啥总断在 syscall 层？ otelhttp 中间件能捕获 HTTP 入口，但到 read/write 系统调用时 trace 就断了——不是 SDK 问题，是默认的 otelgrpc 和 otelhttp 不感知内核态行为，而 eBPF hook（比如 Tracee 或 Parca）生成的 span 缺少 traceparent 上下文链路。

必须手动桥接用户态 traceID 和内核事件。不是加个 SpanContextFromContext 就行，得在关键 syscall 前用 otel.GetTextMapPropagator().Inject() 把 traceID 注入到进程环境变量或 /proc/[pid]/environ 可读位置，再让 eBPF probe 去解析。

• eBPF map 传参太慢，别用 bpf_map_lookup_elem 实时查 traceID，改用 per-CPU array 存当前 goroutine 的 span context 指针（需配合 runtime.LockOSThread()）
• 避免在 net.Conn.Read 这种高频路径反复 Inject，只在连接建立（Accept）和首字节读取时注入一次
• Tracee 的 --output-format=json 输出里字段名是 process_id 不是 pid，对接时字段映射写错会导致 span 找不到父级

Golang 运行时安全真正的麻烦点不在怎么开开关，而在 cgroup、eBPF、Go 内存模型三者交界处那些不报错但悄悄失效的假设——比如认为 runtime.ReadMemStats 的 Alloc 和容器 RSS 一致，或者以为 eBPF 获取的 comm 字段永远等于 Go 的 os.Args[0]。