Go trace 页面打不开时如何确认文件是否完整

Go trace 页面打不开，先不要急着换浏览器或重装 Go。最常见的根因是 trace 数据还没有完整写入文件：trace.Stop() 负责停止追踪并等待写入完成，随后才应该关闭 os.File。如果文件已经完整，再检查 go tool trace 的调用方式和浏览器兼容性。

官方工具地址：https://go.dev/cmd/trace/

先把 trace.Stop 和文件 Close 的职责拆开

runtime/trace.Start(w) 把运行时事件写到传入的 io.Writer。写入可能经过缓冲，因此“程序主体已经跑完”不等于“trace.out 已经可以被查看”。官方文档对 Stop 的语义很明确：它会停止当前追踪，并且只有等追踪写入完成后才返回。

文件关闭是另一件事。f.Close() 释放文件句柄，不能代替 trace.Stop() 等待追踪器收尾。推荐把 defer 注册成下面的顺序，让后注册的 trace.Stop 先执行：

f, err := os.Create("trace.out")
if err != nil {
	log.Fatal(err) // 创建失败时直接结束，避免对无效文件启动追踪
}
defer func() {
	if err := f.Close(); err != nil {
		log.Printf("关闭 trace 文件失败: %v", err) // 记录关闭错误，不覆盖前面的追踪结果
	}
}()

if err := trace.Start(f); err != nil {
	log.Fatal(err) // 启动失败时不继续执行被追踪逻辑
}
defer trace.Stop() // 后注册，故先 Stop，等写入完成后再由上面的 Close 释放句柄

runWork()

反过来写成“先注册 trace.Stop、再注册 f.Close”，defer 执行时就会先关闭文件，追踪器后续写入可能失败，留下大小异常或无法解析的文件。

用两层检查确认问题落在哪一层

排障时把问题拆成“文件层”和“查看器层”。文件层先确认路径、大小和修改时间是否符合预期；不要把一个刚创建但仍在增长的空文件交给查看器。

# 先确认文件存在且大小稳定；下面只是排查命令，不代表固定输出
ls -lh trace.out
wc -c trace.out

# 文件确认后再交给 Go 官方查看器
go tool trace trace.out

官方文档列出的 trace 来源包括 runtime/trace.Start、net/http/pprof 和 go test -trace。测试场景可以直接使用：

# 生成测试追踪文件，包名按项目实际路径替换
go test -trace=trace.out ./...

# 用 go tool trace 打开已完成的文件
go tool trace trace.out

如果文件稳定、命令也能启动而“View trace”页面仍异常，优先换到 Chrome 或 Chromium 测试。Go 官方说明各种 pprof-like profile 可在不同浏览器使用，但 trace viewer 主要在 Chrome/Chromium 上测试。

异常退出时，defer 为什么没有帮你收尾

正常返回、普通 panic 展开时，defer 通常有机会执行；但 os.Exit 会直接结束进程，不执行 defer，log.Fatal 也采用这条路径。于是即使代码表面上写了 defer trace.Stop()，异常分支仍可能没有完成最后一段写入。

采集 trace 的程序可以把错误返回给上层，由最外层统一退出；不要在追踪范围内用 log.Fatal 作为快捷错误处理。若必须响应信号，也要让主流程先停止采集、等待 Stop 返回，再结束进程。这样检查文件时，大小和内容才有明确的完成点。

常见问题

trace.out 不为空，为什么还是打不开？

非空只说明写入过数据，不代表格式完整。先确认采集进程已经执行完 trace.Stop，再复查查看命令和浏览器。

只调用 trace.Stop，不调用 Close 可以吗？

不建议。Stop 等待追踪写入，Close 负责释放文件资源；两者职责不同，应该按 Stop 后 Close 的顺序完成。

go test -trace 生成的文件也要手动 Stop 吗？

不需要。go test -trace 由测试工具负责采集和收尾；手动写入文件的程序才需要自己维护 Start、Stop 和 Close 生命周期。