可用 runtime.NumCPU() 获取逻辑 CPU 数、runtime.NumGoroutine() 获取瞬时 Goroutine 数，但需注意其局限性：前者含超线程且容器中常返回宿主机值，后者为快照且含系统 goroutine，仅宜趋势观察。
怎么用 runtime 包拿 CPU 核心数和 Goroutine 数量
Go 的 runtime 包不依赖外部系统调用，适合轻量实时监控。但要注意：runtime.NumCPU() 返回的是逻辑 CPU 数（含超线程），不是物理核心；runtime.NumGoroutine() 是瞬时快照，高并发下可能刚读完就变了。
-
runtime.NumCPU()在容器里常返回宿主机值，Kubernetes 中需配合/sys/fs/cgroup/cpu/cpu.cfs_quota_us判断是否受限 -
runtime.NumGoroutine()不区分用户 goroutine 和 runtime 系统 goroutine，实际业务中建议只做趋势观察，别设绝对阈值告警 - 别在 HTTP handler 里高频调用——它虽快，但每毫秒调一次仍会累积可观开销
示例：获取当前 goroutine 数并记录日志
log.Printf("active goroutines: %d", runtime.NumGoroutine())
为什么 os/exec.Command("uname", "-m") 比 runtime.GOARCH 更可靠
runtime.GOARCH 是编译时确定的架构（比如 amd64），而真实运行环境可能是容器里被 qemu-user-static 重定向的 arm64 二进制。这时 GOARCH 会误导你判断硬件能力。
- 用
os/exec.Command("uname", "-m")能拿到内核报告的真实机器架构，比如aarch64或x86_64 - 注意权限：某些精简容器镜像（如
scratch）没uname，得 fallback 到读/proc/sys/kernel/ostype或直接捕获exec: \"uname\": executable file not found in $PATH错误 - Windows 下要换用
os/exec.Command("cmd", "/c", "echo %PROCESSOR_ARCHITECTURE%")，别硬套 Linux 命令
获取内存使用率时，runtime.ReadMemStats 为什么不能直接除以总内存
runtime.ReadMemStats 返回的是 Go 进程自身堆内存统计（Alloc、Sys 等），和系统级内存使用率是两回事。直接用 MemStats.Alloc / totalRAM 会严重低估——因为没算 OS 缓存、其他进程、甚至 Go 的未释放 mmap 内存。
立即学习“go语言免费学习笔记（深入）”；
- Linux 下真要系统内存率，得读
/proc/meminfo，解析MemTotal:和MemAvailable:（不是MemFree:） -
MemStats.Sys包含了向 OS 申请的所有内存（含未映射页），但它不含 Go 以外的进程内存，也不能反映 swap 使用情况 - 如果只是想防 OOM，盯住
MemStats.HeapInuse+MemStats.StackInuse的增长趋势，比算百分比更有意义
示例：安全读取 /proc/meminfo
data, _ := os.ReadFile("/proc/meminfo")
// 解析 MemAvailable: 1234567 kB
监控面板里显示 uptime，别用 time.Since(startTime) 简单代替
time.Since(startTime) 只反映进程存活时间，但监控面板常需要“系统已运行多久”。比如进程重启过，用户却以为服务一直在线——这会造成误判。
- Linux 下读
/proc/uptime第一个字段才是系统启动至今的秒数（精度 0.01s），更权威 - macOS 得用
sysctl -n kern.boottime，解析sec = 1712345678字段再算差值 - 注意：
/proc/uptime在容器里默认和宿主机一致，若需容器内 uptime，得挂载/proc并确认 cgroup v1/v2 行为（v2 下/proc/uptime仍为宿主机值）
容易漏的一点：所有从 /proc 读的文件，都得加错误处理，否则容器没权限时整个监控指标会静默失败。
