更强大的 Go 执行追踪

Go 执行追踪的感知收益与开销

• 许多评论者对新的追踪能力感到兴奋，并愿意接受 1–2% 的开销。
• 一位从业者表示，他们已在生产环境中以大规模、真实负载使用执行追踪，实际开销很少超过约 1%，而且有些内置功能依赖它，这表明这些说法在非病理性情况下是现实的。
• 也有人对始终开启追踪保持轻微的警惕，但如果开销数字成立，他们认为这很值得。

Go 工具链与其他生态系统

• Go 的集成式工具（测试、基准测试、性能分析、交叉编译、文档、基础 lint、模块支持等）因其简洁性而广受赞赏（“一个二进制文件，直接就能运行”）。
• 批评者认为，“标准化但基础”的工具限制了可配置性和打磨程度，和专门化生态相比有所不足。
• Java 反复被提及为在工具链方面总体仍属“最佳级别”（尤其是堆/内存分析、实时调试、JFR 风格的飞行记录），尽管 Go 被认为正在追赶。
• JS/TS 工具链常被描述为碎片化且配置繁重；Go 的做法被视为对这种状况的一剂解药，不过也有人看重 TS 的可配置性。

标准库的规模、质量与理念

• Go 的标准库因干净、稳定而广受好评，尤其在 HTTP 和网络方面表现出色；很多人表示自己几乎不需要第三方库。
• 也有人指出一些“藤壶”式问题：遗留包、context 的泛滥、log 与 log/slog、math/rand 的问题、http.Client 的别扭，以及 CSV、XML、堆转储等较弱领域。
• 关于“庞大的标准库 vs 小核心 + 良好的依赖管理”（Go vs Rust/Node 风格）的争论一直存在。有些人把重度依赖文化称为“疯狂”；另一些人则认为，广泛的标准库不可能覆盖所有深度，而且演进缓慢。

术语与追踪粒度

• “执行追踪”让一些人感到困惑，他们原本以为会是指令级或函数级追踪。在 Go 中，这主要指的是 goroutine/runtime 事件追踪，并在事件点附带栈信息。
• 文章澄清，Go 并不提供完整的指令/函数追踪器；当前功能更接近调度器/runtime 追踪。

错误处理与堆栈跟踪

• 一些评论者对错误缺乏内建堆栈跟踪感到不满，导致需要通过 grep 搜索错误字符串。
• 另一些人强调 Go 的理念：错误是普通值，显式包装并附带上下文，而堆栈跟踪主要用于崩溃/panic，因为其成本较高。
• 这里提到的常见做法是：自定义包装器只在需要的地方附加堆栈跟踪（例如用于日志或 Sentry），以运行时开销换取更好的诊断能力。