flight recorder 与持续 execution trace 应如何选择

选择很直接：如果你知道要观察的开始和结束，例如一次测试、基准、命令行任务或可控复现，就用 runtime/trace.Start 与 Stop 记录完整区间；如果服务会运行很多天，异常出现前无法预知，而且你只想保留问题发生前的最近一段执行历史，就用 runtime/trace.FlightRecorder。前者像一次完整会话录像，后者像不断覆盖旧内容、触发后才保存的行车记录仪。

我第一次给长驻服务接 execution trace 时，直觉是“既然能一直写文件，就先持续写着”。很快我就发现，真正难的不是启动追踪，而是文件会持续增长、异常区间难定位、绝大多数数据并没有问题。Flight recorder 改变的正是保存策略：运行时仍采集事件，但只维护一个受时长与大小约束的移动窗口，需要时再调用 WriteTo 快照。

官方参考：https://go.dev/blog/flight-recorder、https://pkg.go.dev/runtime/trace、https://go.dev/doc/diagnostics。

先用故障发生时机确定项目目标

这次做一个很小的 trace-lab：同一段模拟工作负载，通过 -mode=session 或 -mode=flight 选择采集方式。项目并不比较谁“更高级”，只把两种模式放进相同边界里观察：什么时候启动、数据保存到哪里、何时停止，以及什么条件下才生成文件。

准备一个可切换的 trace-lab

项目只需要标准库。main 解析模式、运行时长和是否触发快照，再把相同的工作负载交给不同采集函数。这样不会把“业务做了什么”和“trace 如何保存”混在一起。

package main

import (
	"context"
	"flag"
	"fmt"
	"os"
	runtimeTrace "runtime/trace"
	"sync"
	"time"
)

func main() {
	mode := flag.String("mode", "session", "采集模式：session 或 flight")
	duration := flag.Duration("duration", 5*time.Second, "模拟工作持续时间")
	trigger := flag.Bool("trigger", true, "flight 模式是否写出快照")
	flag.Parse()

	// 用统一超时限定小项目，便于比较两种采集边界。
	ctx, cancel := context.WithTimeout(context.Background(), *duration)
	defer cancel()

	var err error
	switch *mode {
	case "session":
		err = runSessionTrace(ctx, "session.trace")
	case "flight":
		err = runFlightRecorder(ctx, "flight.trace", *trigger)
	default:
		err = fmt.Errorf("unknown mode %q", *mode)
	}
	if err != nil {
		// 示例直接输出错误并返回非零状态，方便脚本判断失败。
		fmt.Fprintln(os.Stderr, err)
		os.Exit(1)
	}
}

环境要求是 Go 1.25 或更高版本，因为 runtime/trace.FlightRecorder 从 Go 1.25 进入标准库。持续 trace 的 API 更早就存在，但为了让同一项目同时编译两种模式，整体版本仍以 1.25 为下限。

持续 trace 适合边界明确的完整会话

trace.Start 接收一个 io.Writer，启用后会把执行事件持续写给它；trace.Stop 停止当前追踪，并在所有 trace 写入完成后返回。对短测试来说，这种语义很舒服：开始点、结束点和输出文件都由调用方明确控制。

func runSessionTrace(ctx context.Context, filename string) error {
	f, err := os.Create(filename)
	if err != nil {
		return fmt.Errorf("create session trace: %w", err)
	}
	defer f.Close()

	// Start 之后的运行时事件会持续写入同一个文件。
	if err := runtimeTrace.Start(f); err != nil {
		return fmt.Errorf("start execution trace: %w", err)
	}
	// Stop 会等待追踪数据写完，必须在关闭文件之前执行。
	defer runtimeTrace.Stop()

	runWork(ctx)
	return nil
}

func runWork(ctx context.Context) {
	var wg sync.WaitGroup
	for worker := 0; worker 

这种模式最让我安心的地方是“没有猜测”：如果任务只运行 5 秒，文件就是这 5 秒的完整会话。但把它原样搬到长期服务里，文件大小会不断增长，后续分析还要从大量正常区间中寻找少数异常。官方 Flight Recorder 文章也把 Start/Stop 更适合的场景归为测试、微基准、命令行工具或已知关注区间。

Flight recorder 适合异常发生后的最近窗口

Flight recorder 同样采集 execution trace 事件，但把最近数据保留在内存窗口中。MinAge 是事件年龄的下界目标，MaxBytes 是窗口大小上界提示，而且 MaxBytes 优先；它们都不是最终快照字节数或总内存开销的硬保证。Go 官方博客建议，可把 MinAge 设为目标故障窗口的大约两倍，再按服务事件量配置 MaxBytes。

func runFlightRecorder(ctx context.Context, filename string, trigger bool) error {
	fr := runtimeTrace.NewFlightRecorder(runtimeTrace.FlightRecorderConfig{
		// 小项目保留最近两秒；生产值应按故障窗口和事件量估算。
		MinAge:   2 * time.Second,
		MaxBytes: 16 

这里的 -trigger 只是小项目里的故障信号替身。真实服务可以把它替换为请求超时、健康检查失败、队列积压或业务不变量破坏。需要注意，当前一个进程只能激活一个 FlightRecorder，同一时刻也只能有一个 goroutine 执行 WriteTo；如果多个告警都能触发快照，应在业务层做单并发或合并。

本地运行时只检查三个结果

把代码保存为 main.go 后，可以分别运行两种模式。下面的命令块保留了中文注释，执行时不会依赖第三方包。

# 记录一个边界明确的五秒完整会话，预期生成 session.trace。
go run . -mode=session -duration=5s

# 维护移动窗口，并在模拟触发条件为真时生成 flight.trace。
go run . -mode=flight -duration=5s -trigger=true

# 不触发快照时仍会记录到内存窗口，但请求结束不生成 flight.trace。
go run . -mode=flight -duration=5s -trigger=false

验收时不要比较两个文件谁更大，因为它们表达的时间范围不同。只检查三件事：命令正常退出；该模式该生成的文件存在且非空；文件能被 go tool trace 读取。分析命令如下：

# 打开完整会话 trace，检查整个已知区间。
go tool trace session.trace

# 打开触发时刻之前的移动窗口快照。
go tool trace flight.trace

go tool trace 展示调度、goroutine、系统调用和 GC 等运行时事件。若目标只是找 CPU 热点或分配热点，应先用 pprof；execution trace 的优势是把“正在执行”和“为什么没有执行”放在同一时序视图中。

生产选择取决于你能否预知观察区间

我现在会先问一个问题：异常发生前，系统是否知道“从现在开始记录”？如果答案是肯定的，持续 trace 更直接；如果答案是否定的，而服务只能在超时或失败出现后才知道有问题，FlightRecorder 才真正发挥价值。

官方文档说明，FlightRecorder 可以与一个 trace.Start 消费者同时活动。这个能力适合短时间的专项调查：移动窗口继续保留，另一个消费者记录已知区间。但我不会把“双开”当默认配置，因为它会重复采集和保存相近事件，也让资源预算、告警触发和文件管理更复杂。先选主模式，只有明确知道第二份数据解决什么问题时再并存。

常见问题

FlightRecorder 能完全替代 trace.Start 吗？

不能。它强调最近窗口和事后触发，不保证保存从程序启动到结束的完整历史。已知区间、短任务和完整会话仍然更适合 trace.Start。

MaxBytes 能保证快照文件绝不超过这个大小吗？

不能。标准库把它描述为窗口大小上界提示，并明确说明它不保证 WriteTo 的最终输出大小，也不保证总内存开销始终低于该值。容量规划要留余量，并在目标服务负载下观察。

持续 execution trace 可以一直开在生产环境吗？

API 可以持续到调用 Stop，但输出量、写入成本、文件轮转和分析难度都会随时间增加。生产中应限制区间和存储预算；对无法预知的稀有故障，FlightRecorder 通常更合适。

两种模式生成的文件都用 go tool trace 吗？

是。两者保存的都是 Go execution trace 数据，差别主要在采集窗口和写出策略，不是分析工具。