Go runtime.SetCrashOutput 如何把崩溃信息写入独立文件：句柄生命周期与并发安全

服务进程遇到未恢复的 panic 时，终端里的堆栈往往会随着进程退出一起消失。Go 1.23 提供的 runtime/debug.SetCrashOutput 可以把同一份崩溃报告额外写进文件或管道，适合保留现场，但它并不是一个可以在 panic 之后慢慢收尾的日志接口。

SetCrashOutput 会复制传入文件描述符；调用成功后可以立即关闭原始文件，但要先确认文件已经打开、目录可写，并记住重复调用会覆盖前一次的附加输出目标。

先分清：它接住的是哪类崩溃

SetCrashOutput 处理的是运行时最终要输出的 fatal crash report。最常见的触发方式是 goroutine 中没有被 recover 捕获的 panic；栈信息会照常写到标准错误，同时再复制一份到你提供的文件。

这和在业务函数外围包一层 recover 不一样。recover 适合把可预期的业务失败转成响应，SetCrashOutput 适合在进程无法继续运行时留下最后的诊断材料。不要把它当成普通应用日志的轮转方案。

最小实现：打开文件后绑定崩溃输出

下面的程序只做三件事：main 打开 crash.log，调用 SetCrashOutput，再让未处理的 panic 结束进程。文件打开失败或绑定失败都应该直接报错，因为这时还没有可靠的崩溃留痕能力。

package main

import (
    "log"
    "os"
    "runtime/debug"
)

func main() {
    crashFile, err := os.OpenFile("crash.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0600)
    if err != nil {
        log.Fatal(err)
    }

    if err := debug.SetCrashOutput(crashFile, debug.CrashOptions{}); err != nil {
        _ = crashFile.Close()
        log.Fatal(err)
    }
    _ = crashFile.Close()

    panic("cache index is inconsistent")
}

这里的 close 不是遗漏：文档明确说明 API 会复制文件描述符，所以 SetCrashOutput 返回成功后，调用方持有的 crashFile 可以关闭。真正由运行时持有的附加输出目标仍然有效。

句柄生命周期：为什么成功后可以关闭原文件

这段代码最容易被误改成“永远不关闭文件”。正确边界是：在 SetCrashOutput 返回前，crashFile 必须保持有效；返回成功后，运行时已经复制了文件描述符，原始句柄不再承担写入责任。

如果绑定失败，不能继续假设文件会收到崩溃报告。示例先关闭 crashFile，再让 log.Fatal 写出错误并退出，这样不会留下一个看似配置成功、实际没有目标的状态。

重复配置与并发替换，别用错场景

一个进程只有一个额外的崩溃输出目标。再次调用 SetCrashOutput 会覆盖之前的目标；传入 nil 则关闭额外输出。启动阶段配置一次通常最稳妥，避免不同模块互相覆盖。

如果程序正在崩溃，而另一个 goroutine 同时替换目标，已经开始的部分输出可能仍写入旧文件，即使新的调用已经返回。这意味着切换日志文件不能被当成严格的原子分流，也不适合拿来做高频动态路由。

几个容易误判的边界

调用后立即删除文件会怎样？

API 复制的是文件描述符，不是把文件内容复制一份。Unix 下删除文件名后，已打开的描述符可能仍指向无名 inode，最终报告未必出现在你期待的路径上，所以不要在绑定后立刻删除或替换目标文件。

能不能用它记录主动 recover 的 panic？

不能直接这样理解。已经被 recover 处理的 panic 不会继续走未处理崩溃报告路径；这类错误应该由业务日志、错误上报或显式堆栈记录负责。

文件权限应该怎么设？

示例使用 0600，只让运行进程用户读写。生产环境还要检查目录权限、磁盘空间和日志采集器是否能读取；不要为了“方便排查”把崩溃报告设成所有用户可写。

上线前的验收动作

先在临时目录运行最小程序，确认进程退出后 crash.log 存在，并且里面同时包含 panic 文本与 goroutine 栈。再检查启动失败场景：把日志目录改成不可写，程序应该在 SetCrashOutput 失败处退出，而不是继续运行并给人“已经启用崩溃落盘”的错觉。

如果要接入监控进程，可以把管道文件描述符传给 SetCrashOutput，但监控端必须设计好读取、落盘和自身退出的边界。API 能提供最后一份报告，不会替你解决报告传输失败后的重试。

相关问题

SetCrashOutput 会停止标准错误输出吗？

不会。它增加一个附加文件目标，标准错误仍然会收到运行时报告。

调用两次会得到两份文件吗？

不会。后一次调用替换前一次目标；需要多路分发时，应交给管道后的监控进程处理。

为什么不在 defer 里调用它？

未处理 panic 的最终报告阶段不是普通函数返回路径，靠 panic 末尾的 defer 才配置目标通常已经太晚。应在进程启动阶段完成绑定。

把它放在启动阶段，留下可解释的最后现场

SetCrashOutput 的价值在于把运行时已有的崩溃报告多保存一份，而不是改变 panic 的处理语义。启动时打开受控权限的文件，检查返回错误，成功后关闭原句柄；不要重复动态覆盖，也不要把它和业务 recover 混为一谈。按这条边界接入后，崩溃现场才既能留住，也不会制造一个虚假的“日志已接管”状态。