Sixty 对比 Sentry

Sentry 擅长什么

Sentry 是现存最好的错误追踪工具，就它做的那件事而言，没有什么可辩的。一条把源码映射回去的调用栈、问题开始的那个版本、动过那几行的那个 commit、通向它的操作面包屑，还有一段会话回放 —— 当你的应用抛异常时，Sentry 把整个现场交到你手上，而且是在安装完几分钟之内。

它也早已走出了错误这一块。它把 N+1 数据库查询当作一等公民的问题来检测，按路由跟踪 Web Vitals，盯着跨版本的性能回归；而 Seer —— 现在是固定价、用量不限，并且已经伸进本地开发和代码评审，而不只是生产环境 —— 会给一个 bug 找出根因并提出补丁。这一页上的所有东西里，它离 Sixty 做的事最近，而且对多数人来说它已经装好了。

Sentry 的价格是一名开发者免费；Team 每月26美元起，Seer 每位贡献者40美元起，依据的是 他们自己的价格页面 在August 2026的公布内容。Sixty 是每month €14.99，固定价。

Sixty 有什么不一样

差别在于什么算问题。Sentry 是围绕事件建起来的 —— 有事发生了，位置在这里。这个模型用在崩溃上完全正确，而对那些代价高的情况它无话可说：返回了 200 的请求、成功了却空着回来的查询、提交了却什么也没做的表单、没接任何处理函数的按钮。没有东西抛出异常，所以 Sentry 里什么都没有，而某个人仍然对着一个不工作的界面。

这也是 Seer 的边界，而这里值得说准确一点，因为 Seer 是真的好。它是一个调试用的助手，而调试的起点是一个已经自己冒出来的缺陷。把它对准一个没有任何东西抛异常的应用，它就没有根因可查 —— 那个把查询形状从三十行变成三万行的回归，压根没有产生任何可供它出发的事件。

Sixty 则是围绕比较建起来的。它没有「事件」这个概念：它知道这个操作平时返回什么、平时发起多少次数据库调用，并在上一次部署改变了这些时告诉你。一条从三十行变成三万行的查询什么都不会抛，但它会出现在动态里。一条开始把所有东西都过滤掉的行级安全策略也一样 —— 那是这类应用最常见的损坏方式，而且在任何地方都不产生错误。

另一个诚实的差别是隐私，而且它是双向切的。Sentry 默认收集 IP 地址，你附上用户 ID 它就会保存，会话回放会记录某个人在你页面上做了什么 —— 这确实有用，也正因如此人们才会打开它。Sixty 一样都不收，而且收不了：URL 会被缩成形状，查询里的值会在你自己的进程里被剥掉，然后才发送。这意味着 Sixty 永远无法告诉你是谁碰上了 bug。这同样意味着，装上它不会给你的同意横幅添任何东西。

并排来看

和 完整对比 问每个工具的是同样 12 个问题，Sixty 输掉的那两行也照样留在里面。

该选哪一个

这两者并不互斥，老实的答案往往是「都要」。这里没有任何东西拒绝和 Sentry 一起跑，而且很多人确实两个都留着。

大家真正会问的问题

• 我应该同时用 Sixty 和 Sentry 吗？

  这是常见的答案，而且两者并不冲突 —— 它们盯的东西不同。Sentry 抓抛出来的东西；Sixty 抓一次部署前后改变了形状的东西，以及那些一边失败一边报告成功的东西。如果你只想留一个，而你的应用经常崩溃，那就留 Sentry。如果你的应用不崩溃却依然不对劲，那正是 Sixty 被造出来要处理的情况。

• Sentry 也能检测 N+1 查询。区别在哪？

  Sentry 是在一条 trace 内部找出 N+1 模式 —— 一次请求里有十四条相似的查询，不管这件事是不是新出现的，它都会标出来。Sixty 是跟上一个版本比较：每次渲染一条查询变成了十四条，发生在这次部署，出现在这个操作上。前者告诉你这个形状不好；后者告诉你是哪次改动把它弄成这样的 —— 而后者才是决定你接下来做什么的那部分。

• Seer 已经能从我的编辑器里修 bug 了，为什么还要再加东西？

  因为 Seer 需要一个 bug 作为起点，而这个产品之所以存在的那类故障根本不产生 bug。Seer 是一个对准某个问题的调试助手 —— 一个异常、一条 trace、一个 Sentry 已经标出来的回归 —— 而它非常擅长从那里走到一个补丁。Sixty 的活是再往前一步：在没有任何地方报告过问题的情况下，注意到这次部署改变了某个操作的行为。价格上它们也不是同一笔买卖 —— Seer 是在 Sentry 套餐之上，每个有贡献的开发者每月 40 美元，而 Sixty 是按应用 €14.99 的固定价。

• Sentry 有 suspect commits，这不是一回事吗？

  意图相同，路径不同，而这个不同决定了各自在哪儿好用。Sentry 拿调用栈指向的那一行，去问 git 谁最后动过它 —— 对崩溃来说这是个好答案，因为崩溃有一行可指。性能回归常常没有：查询本身没变，是调用它的地方开始跑十四次。Sixty 则从部署出发。一条发现是一个版本与上一个版本的比较，两端都是 commit，所以在做任何收窄之前，候选集合就已经是完整的 —— 而收窄它的依据，是哪次改动动过这条发现所在的文件。

• Sixty 有会话回放吗？

  没有，以后也不会有。回放意味着记录一个人在你的页面上做了什么，而这里的整个设计就是：关于你的用户的任何东西都不离开你的应用 —— 没有会话 ID，没有 URL，没有页面文本。这是一个有意的取舍：我们能告诉你什么坏了、坏得多频繁，但永远不会告诉你它发生在谁身上。

其他对比