Go标准库runtime包仅提供进程自身运行时信息，无法获取系统级信息；CPU型号、内存总量等需用gopsutil/v3等第三方库或直接调用系统接口。
Go 标准库的 runtime 包只能拿到**当前 Go 进程自身的运行时信息**，不是系统信息。想查 CPU 型号、内存总量、磁盘使用率、主机名、系统 uptime 等，必须用第三方库或系统接口。
runtime.NumCPU() 返回的是逻辑核数，不是物理核心，也不受容器限制
它读取的是 OS 在启动时报告的可用逻辑处理器数（含超线程），比如 i7-10700K 返回 16，但物理核心只有 8。这个值在程序启动时固化，不会随 GOMAXPROCS 变动，更不会感知 cgroups 限制——Docker/K8s 里它仍返回宿主机总核数。
- 要获取物理核心数：Linux 下需执行
sh -c 'grep "core id" /proc/cpuinfo 2>/dev/null | sort -u | wc -l' - 要获取容器实际 CPU 配额：读
/sys/fs/cgroup/cpu/cpu.cfs_quota_us和cpu.cfs_period_us - 别用它做“是否该扩容”的判断依据；它只是调度单位上限，不是资源水位
runtime.ReadMemStats() 给的是 Go 堆快照，不是系统内存
runtime.ReadMemStats() 返回的 MemStats.Alloc 是当前堆上活跃对象字节数，Sys 是 Go 向 OS 申请的总内存（含未释放页）。它们都不含栈、CGO 分配、共享库、VDSO 或其他进程内存。
- 查系统总内存和可用内存：Linux 读
/proc/meminfo解析MemTotal:和MemAvailable:；macOS 用sysctl hw.memsize；Windows 调GlobalMemoryStatusEx - 高频调用
ReadMemStats会 STW，生产环境建议 ≥1s 间隔 - 刚分配大量对象但没 GC？
Alloc会严重偏低；手动触发runtime.GC()再读可缓解，但别在关键路径上用
用 gopsutil/v3 才能跨平台获取真实系统信息
标准库不提供主机名、CPU 型号、磁盘容量、网络 IO、系统 uptime 等能力。gopsutil/v3 封装了各平台底层接口（Linux /proc、Windows WMI、macOS host_info），是生产首选。
立即学习“go语言免费学习笔记（深入）”；
- 安装：
go get github.com/shirou/gopsutil/v3；Windows 需额外go get github.com/StackExchange/wmi - 必须启用 cgo（
CGO_ENABLED=1），否则 Windows/Linux 部分功能失效 - 示例：获取主机名和内存总量
import (
"github.com/shirou/gopsutil/v3/host"
"github.com/shirou/gopsutil/v3/mem"
)
info, _ := host.Info()
memInfo, _ := mem.VirtualMemory()
fmt.Println("Hostname:", info.Hostname)
fmt.Println("Total RAM:", memInfo.Total/1024/1024, "MB")
注意：cpu.Percent(0, false) 才是实时 CPU 使用率；cpu.Info() 只返回静态型号和核数，不是负载。
runtime.Version() 不可靠，查 Go 版本得用 goversion 命令
runtime.Version() 返回的是编译时嵌入的运行时版本字符串，发布时间字段可能滞后（比如显示 2026 年 4 月），且无法区分 patch 版本。真正要确认当前环境 Go 工具链版本，必须调用外部命令：
os/exec.Command("go", "version").Output()- 或直接解析
runtime/debug.ReadBuildInfo()中的GoVersion字段（仅限模块化构建） -
runtime.GOOS和runtime.GOARCH是编译时确定的，不能反映运行时真实架构（比如 qemu 模拟的 arm64 容器里仍是amd64）
最易被忽略的点：所有系统级指标（CPU 使用率、内存总量、磁盘空间）都依赖外部 I/O 或系统调用，无法靠 runtime 包单打独斗；而任何跨平台抽象库（如 gopsutil）在容器或精简镜像中都可能因缺失命令、权限或 cgroup v2 支持而静默失败——务必加 fallback 和错误日志。
