程序员996猝死背后：心脏停跳后，工作群仍在@他需求

这两天，一则关于“32岁程序员周末晕倒后猝死”的新闻，在圈内引发了广泛的关注与讨论。对于我们这些身处相同行业的程序员来说，这则消息带来的冲击与共鸣尤为强烈。

逝者名叫高广辉，32岁，正是我，以及许多同行所处的年纪，人生轨迹也惊人地相似：出身普通家庭，靠兼职完成学业，对技术抱有纯粹的热情，并在28岁那年成功晋升为部门经理。在他猝死前的一周，最早的下班时间是晚上9点多，最晚则到了11点。

说实话，在互联网行业里，这样的作息甚至称不上极端，它不过是我们许多人早已习以为常的节奏。真正让人感到刺痛与窒息的，是新闻中披露的那条时间线：早上拨打急救电话，送医时已被判定为临床死亡；而到了晚上，他竟被拉进一个新的技术群，群里还有人在问：“高工帮忙看下这个订单”；深夜，甚至还有私聊消息提醒：“周一早上有紧急任务”。

他的心脏已经停止了跳动，但工作群的消息，仍在不知疲倦地持续“@”着他。

在那一刻，我深刻地感受到：对公司和系统而言，一个人或许只是一个随时可以被替换的“资源ID”；但对于生命本身而言，却永远只有一次，没有重试，也没有回滚。

我们这一代人的日常，有时真像下面这段永不停歇的代码循环：

public void 日常循环() {
    while (还有任务() && 是否活着()) {
        if (deadline临近()) {
            加班();
            if (身体不适()) {
                忽略(); // 等这个项目结束就好了
            }
        }
        工作();
    }
}

private boolean 还有任务() {
    return true;
}

这段伪代码的问题一目了然：它的循环体缺少一个有效的终止条件。可悲的是，我们并非不知道问题所在，而是常常“不敢停”。因为一旦停下，就可能被贴上“不够努力”的标签，担心自己在飞速运转的齿轮中被轻易替换。

我们总是这样安慰和承诺自己：

• 等这个项目上线就好了。
• 等这个版本发完就轻松了。
• 等年底拿了奖金再好好休息。

然而，在互联网这个高速迭代的行业里，永远有下一个紧急需求、下一个重要版本、下一个“不容有失”的项目。高广辉的生命，永远地停在了他人生版本的v1.0，没有热修复的机会，也无法再进行任何迭代。

如果他的离去，仅仅换来朋友圈里片刻的叹息与转发，而后我们依然在凌晨的办公室中默默提交代码，那么这场悲剧就真的失去了所有意义。

努力上进没有错，但请不要拼命。我们熟谙数据结构，知道“栈溢出”（Stack Overflow）必然导致程序崩溃。那么，当生活的“工作栈”已被任务压满时，为何不主动为自己设定一个边界？我们调试代码时，懂得在关键位置设置“断点”（Breakpoint）。那么，在人生的漫长运行中，为何不能为自己设置一个定期的“健康断点”？

这不仅仅是一篇写给同行的杂谈，也是写给我自己的警示录。愿我们都能有命看到自己代码的下一个稳定版本，愿所有的努力都不再以透支生命为代价。

高广辉，愿你在另一个世界，没有无休止的加班，也没有催命的deadline。也希望仍在屏幕前的我们，能更早地学会平衡工作与生活这门至关重要的职场软技能。