凌晨 3 点 debug 一个时区 bug

凌晨 3 点 debug 一个时区 bug。第 17 次觉得自己应该转行种地。 时区这种东西，本质上是一个「全球分布式系统对齐」问题。UTC 存、local 显、跨时区计算用 lib，每个点都正确，但组合起来总有某个边界 case 出问题——比如用户在 23:30 创建了一条笔记，应用层以为是今天，存到数据库用 UTC，结果到第二天 0:30 显示是「昨天」。 每次撞上时区 bug 都想：为什么不用单一时间？为什么不强制 UTC 显示？为什么不让用户自己选时区？但这些方案都有各自的代价。单一时间意味着所有用户看到的都是 UTC，体验差；强制 UTC 显示和单一时间本质一样；让用户选时区又增加了 onboarding 摩擦。 种地不会有时区 bug。种地的唯一时间是「季节」和「天气」，不需要精确到秒。所以 debug 失败时，种地的诱惑特别大。 但实际上种地凌晨 3 点也要起床给牛挤奶。所以这个逃避方向也不成立。 凌晨 3 点 debug 时区 bug 真正的危害不是「找不到答案」，而是「找到的错误答案」。人在极度疲惫时倾向于接受第一个看似合理的解释，不再继续追问。我那次找到的「修复」其实只是把 bug 从「23:30 的笔记显示昨天」改成了「00:30 的笔记显示明天」——问题的核心没有解决，只是把边界挪了一下。 事后看，正确的做法是：凌晨 3 点不应该 debug 时区 bug。时区这种东西需要的不是聪明，是清醒。改时区代码的窗口应该排在「睡了一觉、喝了咖啡、上午 10 点到下午 2 点」之间。任何其他时间碰它都是在赌运气。 所以我现在给自己立了一个规矩：晚上 12 点之后，不改任何跟时间、字符编码、并发锁相关的代码。这些是「bug 黑洞」领域，需要大脑满血才能对付。其他代码可以熬，这些不行。这条规矩让我的凌晨 3 点再也不需要了。 2026 年看，「凌晨 3 点 debug」这个场景已经被部分消解了——AI agent 能 7×24 帮你 debug，时区 bug 抛给 Claude Code + 把报错信息贴进去，它能比你更快地定位。但「把判断交给 AI」本身需要清醒——让 AI 在凌晨 3 点 debug，你大概率会接受它给的第一个「修复方案」而不追问；让 AI 在上午 10 点 debug，你才有精力去质疑它的方案。所以规矩要改成：凌晨 3 点不 debug 任何东西——人不行，AI 的输出也不行被人审核。