你有没有遇到过这样的情况：服务器一出点小问题，日志文件就疯狂刷屏，翻半天全是同一行报错——比如Connection refused连刷500次，真正有用的线索反而被埋没了？这可不是日志太多，而是重复日志没拦住。
为啥日志会“复读”？
常见原因挺实在：程序里写了循环重试逻辑，但每次失败都记一条日志；或者监控脚本每秒轮询一次服务状态，连不上就写一行错误，结果1分钟生成60条一模一样的记录。时间戳不同、行号不同，内容却完全一样——系统认不出这是“复读机”，只当它是60个独立事件。
简单又管用的过滤法
不用上复杂中间件，Linux 命令行就能快速筛一遍。比如查看最近的错误日志，去掉连续重复项：
tail -n 200 app.log | uniq注意：uniq只对相邻重复行有效。如果想彻底去重（不管是否相邻），可以加个排序再筛：
tail -n 200 app.log | sort | uniq -c | sort -nr | head -10这条命令能帮你揪出出现次数最多的10条重复日志，顺手就知道哪类错误最“赖着不走”。
写代码时顺便防一手
程序员朋友在打日志前加个小判断，成本几乎为零。比如 Python 里用一个缓存变量记下刚打过的错误内容和时间：
last_log = {"msg": "", "time": 0}
def safe_log(msg):
now = time.time()
if msg == last_log["msg"] and now - last_log["time"] < 30:
return # 30秒内相同日志不重复打
logging.error(msg)
last_log["msg"] = msg
last_log["time"] = now家里路由器后台、智能音箱的调试日志、甚至你写的爬虫脚本，都可以这么处理。不是不让记，是别让屏幕变“回音壁”。
生活里的类比其实很贴切
就像小区门禁系统，有人连续按了10次开门键，难道真要响10次提示音？合理做法是：第一次响“滴”，后面9次静音，顶多在后台记一笔“用户重复触发”。日志也一样——重点不是“发生了多少次”，而是“发生了什么、什么时候开始、持续多久”。把噪音滤掉，真正的信号才听得清。