Go os.ProcessState.SysUsage 为什么不同系统结果不同

我在把 Go 子进程的退出信息接入统一日志时，最容易误判的地方不是 ProcessState 本身，而是 SysUsage() 返回的对象。它的返回类型是 any，文档明确把资源使用信息定义为“系统相关”，所以同一段业务代码在 Unix、Windows 或其他目标上的底层类型和字段语义不应被当成完全相同。

实际处理时可以记住一句话：先确认命令已经产生了 ProcessState，再观察 SysUsage() 的动态类型，最后由平台适配层读取字段；退出码、启动错误和资源统计要分别记录。

官方文档：https://pkg.go.dev/os#ProcessState.SysUsage

先确认 ProcessState 什么时候存在

ProcessState 描述的是已经退出的进程。使用 exec.Command 后，如果进程根本没有成功启动，不能期待它一定有可用的退出状态；而命令已经启动并退出，即使退出码不是 0，也仍然应把退出结果和 Run 返回的错误分开处理。

package main

import (
    "fmt"
    "os/exec"
)

func main() {
    cmd := exec.Command("go", "version")
    err := cmd.Run()

    // Run 返回后，ProcessState 用来描述已经结束的子进程。
    state := cmd.ProcessState
    if state == nil {
        // 启动失败时可能没有退出状态，不能继续读取 SysUsage。
        fmt.Printf("没有可用的 ProcessState: %v\n", err)
        return
    }

    // 退出状态与资源对象是两条信息，先分别记录动态类型。
    fmt.Printf("pid=%d success=%v usage_type=%T\n", state.Pid(), state.Success(), state.SysUsage())
    if err != nil {
        // 非零退出、信号退出等原因由 err 和 ProcessState 共同解释。
        fmt.Printf("命令结束但返回错误: %v\n", err)
    }
}

这里不要把 err != nil 直接等同于“没有资源统计”。启动失败和命令正常启动后返回非零，是两种完全不同的情况。前者可能没有 ProcessState，后者通常已经有可以继续分析的退出状态。

SysUsage 返回值为什么不能直接跨平台解读

SysUsage() 的签名是 func (p *ProcessState) SysUsage() any。它解决的是“把系统提供的资源使用信息暴露出来”，并没有承诺一个跨平台统一的结构体。Go 官方文档以 Unix 上的 *syscall.Rusage 为例，但这个“例如”本身就提醒我们：底层对象取决于目标系统。

以 Go 当前源码的实现关系看，Unix 实现把等待进程时得到的资源结构保存到 ProcessState，Windows 也会把进程时间信息放入系统相关结构；Plan 9 等目标则有自己的实现。即使几个系统都能返回名为 Rusage 的对象，字段可用性和单位也不能仅凭名称推断。

先观察动态类型，再决定读取方式

跨平台公共代码最稳妥的第一步是记录 %T，而不是立即写死一个类型断言。这样排查部署差异时，日志会告诉你当前构建目标究竟返回了什么对象。

package main

import (
    "fmt"
    "os"
)

func printUsageKind(state *os.ProcessState) {
    if state == nil {
        // nil 表示没有退出状态，先结束资源统计分支。
        fmt.Println("usage unavailable: ProcessState is nil")
        return
    }

    raw := state.SysUsage()
    switch value := raw.(type) {
    case nil:
        // 某个目标或异常路径可能没有资源对象，不能强制断言。
        fmt.Println("usage unavailable: SysUsage returned nil")
    default:
        // %T 记录真实动态类型，%v 只用于保留原始对象的可读摘要。
        fmt.Printf("usage_type=%T usage=%v\n", value, value)
    }
}

这个公共函数只负责识别和留痕，不负责解释每个平台的字段。把“发现对象是什么”和“把对象字段转换成业务指标”拆开，后续升级 Go 或切换构建目标时更容易定位变化。

用平台适配层隔离字段差异

如果确实需要最大常驻内存、用户态时间或内核态时间等字段，就把类型断言放到对应平台的文件中。例如 Unix 代码可以单独放在带构建约束的适配文件里；公共包只依赖一个自己的摘要结构，不直接依赖 syscall 的全部细节。

//go:build unix

package usage

import (
    "fmt"
    "os"
    "syscall"
)

type Summary struct {
    Kind string
    Text string
}

func FromProcessState(state *os.ProcessState) Summary {
    if state == nil {
        // 公共摘要用明确的 Kind 表达“没有状态”，避免空指针访问。
        return Summary{Kind: "unavailable", Text: "ProcessState is nil"}
    }

    usage, ok := state.SysUsage().(*syscall.Rusage)
    if !ok || usage == nil {
        // 类型不匹配时保留动态类型，便于发现平台或构建约束配置错误。
        return Summary{Kind: fmt.Sprintf("unexpected:%T", state.SysUsage()), Text: "unsupported resource object"}
    }

    // Unix 字段解释集中在适配层，公共业务不直接读取 Rusage。
    return Summary{Kind: "unix-rusage", Text: fmt.Sprintf("%+v", *usage)}
}

上面的文件只是 Unix 适配示意，具体项目应按需要拆出 Windows 或其他目标的实现，并让每个实现解释自己的字段单位。不要把带有 *syscall.Rusage 断言的文件无条件编译到所有目标，也不要为了追求一个“统一字段”而把不支持的字段填成 0。

如果文章代码只需要记录资源对象类型而不读取平台字段，就保留上一节的公共写法即可。它的优点是跨平台边界更小，代价是日志中只有原始摘要，不能直接得到统一的业务指标。

退出状态和资源统计要分开审计

生产环境通常同时关心三件事：进程是否启动成功、最终是否成功退出、资源统计是否可解释。建议把它们放在一条审计记录的不同字段中，让“命令失败”和“平台不支持某个指标”不会混成同一个告警。

type AuditRecord struct {
    Started bool
    Success bool
    ExitText string
    UsageKind string
    UsageText string
}

func auditCommand(cmd *exec.Cmd, runErr error) AuditRecord {
    record := AuditRecord{}
    if cmd.ProcessState == nil {
        // 没有 ProcessState 时，明确记录启动或等待阶段不可用。
        record.ExitText = fmt.Sprintf("no process state: %v", runErr)
        return record
    }

    record.Started = true
    record.Success = cmd.ProcessState.Success()
    record.ExitText = fmt.Sprintf("pid=%d err=%v", cmd.ProcessState.Pid(), runErr)

    // 资源对象单独记录类型，避免把平台缺失误报成命令失败。
    usage := cmd.ProcessState.SysUsage()
    record.UsageKind = fmt.Sprintf("%T", usage)
    record.UsageText = fmt.Sprintf("%v", usage)
    return record
}

审计时还要留意两个边界：第一，资源统计只表示退出后的系统信息，不是实时采样器；第二，字段的时间单位、是否包含子进程以及内存统计口径，都要按目标系统的文档确认。跨平台公共日志可以记录类型和原始摘要，统一数值指标则必须经过平台适配和口径约定。

常见疑问

为什么 ProcessState 不为空但 SysUsage 是 nil？

退出状态和资源使用对象不是同一个字段。某些目标、构建组合或异常路径可能只有退出状态，公共代码应先判空并保留 %T，不要把 nil 当成进程没有退出。

命令退出码不是 0，还能读取 SysUsage 吗？

可以把两件事分开判断。命令已经启动并结束时，ProcessState.Success() 反映退出是否成功，SysUsage() 反映能否取得资源对象；失败退出并不自动抹掉资源信息。

能不能所有系统都断言成 *syscall.Rusage？

不能把这个判断写成无条件的跨平台约定。官方文档把它作为 Unix 示例，其他目标由各自实现决定。只有在明确的构建目标和对应源码约束下，才应使用平台专属断言。

应该直接把 SysUsage 的字符串写进日志吗？

调试阶段可以保留原始摘要，但长期审计最好同时记录动态类型、退出状态和适配后的字段版本。这样后续改变平台或 Go 版本时，仍能知道数值来自哪一种对象。

总结

os.ProcessState.SysUsage 的关键不是记住某一个结构体，而是接受它的系统相关属性。先用 ProcessState 区分启动与退出，再用 %T 观察资源对象，最后把平台字段放进构建约束明确的适配层；公共日志只消费稳定摘要，并把退出结果和资源统计分别记录。这样同一套 Go 业务在不同系统上的差异会变成可解释的边界，而不是部署后才出现的类型断言 panic。