用户不会告诉你他卡住了，但日志会
每一台服务器都在不停地写日记。用户每点一次按钮、每打开一个页面、每触发一次错误，后台就记下一行。这本日记叫日志（log）——软件运行过程的流水账，本来是为了让工程师排查故障用的。
大多数工程师看日志的方式是「找异常」：哪行红了，哪行报错了，哪里响应超时了。但如果你换一种看法，把日志当成用户行为的录像带，你会看到完全不同的东西。
一行日志背后的三十秒
来看一段很多产品后台都真实存在的日志模式：
14:02:11 用户打开「修改手机号」页面
14:02:19 提交，失败：验证码错误
14:02:40 提交，失败：验证码错误
14:02:58 重新发送验证码
14:03:31 提交，失败：验证码错误
14:03:47 重新发送验证码
14:04:12 重新发送验证码
14:04:40 用户离开了页面，再没回来
在工程师眼里，这可能只是「验证码校验失败 3 次，重发 3 次」——没有红色异常，系统一切正常。但如果你把这段时间轴想象成一个人坐在手机前的样子：他盯着屏幕等短信，短信没来；他把旧验证码又输了一遍，错误；他再点重发，把手机翻过来扣在桌上等，还是没来；最后他放下手机去干别的了。
这不是一次「校验失败」，这是一个人挣扎了两分半钟，然后放弃了。日志里全是这样的呼救，只是它们穿着技术事件的外衣。
大白话：日志就像医院的走廊摄像头。医生（工程师）平时只看心电监护仪报警（系统异常），但摄像头里能看到一个病人扶着墙站不起来，按了三次呼叫铃没人理，最后自己走了。监护仪上一切正常。
挣扎有形状
看得多了，你会发现用户的挣扎在日志里有几种反复出现的「形状」：
- 原地打转：同一个页面来回刷新、同一个按钮反复点。翻译过来是「我没看懂，但我不甘心」。
- 步步后退：一路返回到首页，然后从头再来一遍。翻译过来是「我知道我把自己弄丢了，重来」。
- 断崖：在某一步之后，会话戛然而止。这一步就是整段流程里最难过的坎——它可能只是一个让人看不懂的下拉框。
- 深夜重试：同一个操作在凌晨反复失败。这个人很可能很着急，而且明天还会再来。
每一种形状都是一句没说出口的话。而它们的共同点在于：系统层面一切正常，没有一个报错。如果只看异常监控，这些用户是隐形的。
为什么研发看不到这些
这不能怪工程师冷漠，这里有个结构性的问题：离日志最近的人，恰恰是最不需要这些提示的人。工程师对自己写的软件太熟了，他知道验证码在垃圾短信里、知道那个按钮要点左上角。他看日志时戴着「知情者」的眼镜，自动过滤掉了那些「这有什么好卡住的」的部分。
心理学里管这个叫知识的诅咒——人一旦掌握了某个知识，就很难想象「不知道这个知识」是什么感觉。写软件的人全都中了这个诅咒，而解药恰恰就躺在他们自己的服务器上：日志里那些打转、后退、断崖的轨迹，全都是「不知道的人」留下的脚印。
所以看日志的正确姿势，不是问「系统哪里坏了」，而是问「如果是我的妈妈在用，她会在第几行卡住」。同一个日志文件，这两个问题会带你看到完全不同的东西。
当然，日志里也有真正在「报错」的时刻——那是软件亲口对用户说话的时刻，也是整场对话里最诚实、最容易搞砸的时刻。下一章专门讲它。