Go runtime/debug.SetPanicOnFault 怎样把非法内存访问转成 panic

我第一次认真看 runtime/debug.SetPanicOnFault，是在排查一段使用内存映射文件的代码时。现象很容易被说成“把段错误变成可恢复异常”，但这个说法少了几个关键限定：它针对的是非 nil 地址上的意外故障，只影响当前 goroutine，而且并不是一把通用的内存安全保护伞。

先建立两条行为基线

在默认设置下，Go 运行时把非 nil 地址上的意外 fault 看成严重错误，典型结果是打印诊断并终止进程。对使用 unsafe、内存映射文件或底层设备缓冲区的代码来说，某些 fault 可能是希望由这一层程序接住的边界事件，这时才有理由评估 SetPanicOnFault。

启用后，运行时请求把这类 fault 变成 panic。行为改变的是“故障如何进入 Go 的 panic 处理链”，不是“错误的内存访问变得安全”。指针越界、对象生命周期错误和数据竞争仍然是代码缺陷，不能因为多了一个 recover 就继续使用已经不可信的状态。

用返回值保存旧设置，再包住风险操作

这个 API 的一个实用细节是返回值：返回的是调用前的设置。不要把它当成无关紧要的布尔结果；如果代码运行在共享进程里，局部风险操作结束后恢复旧值，能避免后面的 goroutine 继续继承一个并非它主动选择的运行时策略。

package main

import (
    "fmt"
    "runtime/debug"
)

func runRiskyRegion() (err error) {
    // 保存旧设置，函数结束时恢复调用前的运行时行为。
    old := debug.SetPanicOnFault(true)
    defer debug.SetPanicOnFault(old)

    defer func() {
        if value := recover(); value != nil {
            // 只把这里捕获到的值当作故障报告，不继续使用可疑状态。
            err = fmt.Errorf("fault converted to panic: %v", value)
        }
    }()

    return doMemoryMappedWork()
}

func doMemoryMappedWork() error {
    // 真实项目在这里访问经过严格生命周期管理的 mmap/unsafe 区域。
    return nil
}

示例最重要的不是 recover 的写法，而是范围：先保存设置，再执行一小段明确的底层操作，最后恢复。若把开关放在进程初始化阶段并一直保持开启，所有后续代码都可能处于不同的 fault 语义下，排查边界会变得模糊。

当前 goroutine 是硬边界，不要把它当全局开关

官方文档明确说明，SetPanicOnFault 只应用于当前 goroutine。这个限定很容易在 worker、线程锁定或异步回调场景里被忽略：在 goroutine A 中开启，并不等于 goroutine B 的风险操作也会得到同样的处理。

func worker() {
    old := debug.SetPanicOnFault(true)
    defer debug.SetPanicOnFault(old)

    // 只有当前 worker goroutine 的这段边界采用新设置。
    if err := runRiskyRegion(); err != nil {
        reportFault(err)
    }
}

func startWorkers() {
    go worker()
    go func() {
        // 不能假设这里也自动拥有 worker 的设置。
        runIndependentRegion()
    }()
}

因此，真正需要这个语义的每条执行链都应在自己的 goroutine 入口建立边界。也不要只因为一个 goroutine 负责调度，就假设它创建的其他 goroutine 都会自动拥有同一开关；把风险操作放在同一个明确入口，或由每个执行单元自行设置并恢复。

runtime.Error 的 Addr 只能作为诊断线索

故障转成 panic 后，传给 recover 的值通常表现为运行时错误。官方文档指出，这个 runtime.Error 可能额外提供 Addr() uintptr，用来给出触发 fault 的地址。它适合写入报告，帮助判断是映射区域、指针偏移还是生命周期问题，但结果是尽力而为，并且会受平台影响。

type addressReporter interface {
    Addr() uintptr
}

func reportRecoveredFault(value any) {
    runtimeErr, ok := value.(runtime.Error)
    if !ok {
        logValue(value)
        return
    }

    if addressErr, ok := runtimeErr.(addressReporter); ok {
        // 地址是诊断字段，不应被当成可以再次访问的指针。
        logFault(runtimeErr.Error(), addressErr.Addr())
        return
    }
    logValue(runtimeErr)
}

这里有两个刻意的克制。第一，不把所有 recover 值都强转成 runtime.Error，因为业务代码也可能主动 panic。第二，不根据 Addr() 返回的数值继续读写内存；它是报告中的线索，不是经过验证的有效地址。

把设置、风险操作、恢复和还原排成一条时间线

在值班排查中，我会先看这四个节点，而不是先扩大 recover 的范围：设置是否发生在正确的 goroutine，风险操作是否真的位于设置之后，恢复是否记录了原始 fault，函数返回前是否还原了旧设置。四个节点只要缺一个，结果就可能看起来像“偶尔能救回来”。

func withFaultBoundary(fn func() error) (err error) {
    old := debug.SetPanicOnFault(true)
    defer debug.SetPanicOnFault(old)

    defer func() {
        if value := recover(); value != nil {
            reportRecoveredFault(value)
            err = fmt.Errorf("risk boundary panic: %v", value)
        }
    }()

    return fn()
}

这个结构能让“设置前的值”和“故障报告”同时存在：前者用于恢复运行时状态，后者用于判断是否应该终止当前任务、关闭损坏的资源或让进程退出。不要在恢复函数里悄悄重试同一段未知状态的指针访问，那会把一次可定位的故障变成不可预测的二次损坏。

最容易混淆的四个边界

1. 非 nil 地址与 nil 地址：这个 API 的文档描述是 unexpected non-nil address fault。不要把所有空指针、索引越界和普通业务 panic 都归入同一类。
2. panic 与进程可继续运行：成功进入 recover 只说明这次 panic 在链路中被接住，不能说明原对象、映射区域或底层句柄仍然可信。
3. 当前 goroutine 与全局配置：在一个 goroutine 设置，不代表其他 goroutine 同步获得同样语义；worker 入口应显式建立和还原边界。
4. 地址信息与可用指针：Addr() 返回的是诊断信息，不能直接转成指针再访问，也不能据此绕过资源生命周期检查。

适合落地的最小约定

如果项目确实需要对内存映射或受控的底层访问做故障隔离，可以把约定写成四句：风险操作只在专门的 goroutine 中执行；进入边界时保存并开启设置；恢复时记录 runtime.Error 与可选地址；退出边界前还原旧设置。边界之外的代码仍按普通 Go 错误和 panic 处理，不依赖这个开关兜底。

我的经验是，先用“默认 crash”和“启用后 panic”做行为基线，再决定是否值得增加恢复路径。若不能说明发生 fault 后资源如何废弃、任务如何停止、错误如何上报，就不要只为了让进程不退出而启用它。能被准确关闭和复盘的边界，才是这个 API 真正有价值的地方。

相关问题

• SetPanicOnFault 能修复非法内存访问吗？不能。它只改变特定 fault 的处理路径，根因仍需要修复。
• 开启后所有 panic 都能 recover 吗？不能。只有进入当前 goroutine 的 panic 链且没有在更早层终止的情况，才谈得上 recover。
• 为什么设置后另一个 goroutine 没有变化？因为设置只作用于当前 goroutine，异步执行单元需要自己的边界。
• Addr 返回的值能继续转换成指针吗？不应这样做。它是尽力而为的诊断线索，不是内存访问许可。