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。两者对“已用内存”的定义错位了。
使用 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]。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
