每年整理一次信息源今年是第三回。跟去年比砍掉了 4 个公众号、2 个 RSS 源、1 个付费专栏。不是内容变差了是我的时间变少了。三十多岁的后端工程师能花在看技术内容上的时间从每天 2 小时压缩到 40 分钟信息源必须跟着缩。下面这份清单是筛完之后留下的。不是最好的技术信息源——这说法太扯——而是以我目前的精力和方向投入产出比最高的几个。掘金两个博主的专栏我每篇都看掘金我主要看人不看推荐流。推荐流现在标题党越来越多一文搞懂彻底弄明白这类标题我直接划走。固定追的两个博主码农翻身。老牌技术博主写 Java 生态和系统设计。他的特点是能把复杂的分布式问题拆成故事线不是干巴巴列知识点。去年他写的一系列消息队列到底解决了什么问题的连载从业务场景切入到选型对比比我看的几本中间件书都清楚。更新频率不高但每篇的质量都压得住。Java极客技术。偏向 JVM 底层和并发编程。他的 JVM 调优系列和 GC 日志分析系列我反复看过好几遍。适合那种觉得自己懂了但说不出细节的阶段——看完能把面试时的含糊回答变成有数据支撑的分析。更新比较稳定每周 2-3 篇。InfoQ 后端架构板块InfoQ 的后端板块是我目前唯一还在看的聚合型技术媒体。原因有两个第一它的编辑会做内容筛选不像有些平台全靠算法推荐。你能感觉到有人在选内容不是纯粹堆量。第二InfoQ 的深度文章比例比其他媒体高。同样是讲微服务治理别的平台给你一篇Spring Cloud Gateway 入门InfoQ 给你一篇某公司从 Zuul 迁移到 Gateway 的踩坑记录和性能对比。前者你 Google 一下就有后者才是有价值的信息。缺点是内容偏架构层面对一线 CRUD 开发者不够接地气。但如果你开始参与技术选型或架构评审InfoQ 是绕不过去的。CSDN一个写系统设计的博主CSDN 的内容质量参差不齐是公认的但我关注了一个写系统设计的博主。他的文章不多但每篇都是万字级别的系统设计实战——从需求分析到容量评估到架构图到代码骨架完整走一遍。我关注他不是因为每篇都对有用而是因为他的思考方式值得学。他做容量评估的时候会先算 QPS 再算存储再算带宽每一步都有数字。这种先量化再设计的习惯是在很多讲系统设计的书里学不到的。CSDN 平台本身我不怎么逛主要是用 RSS 订阅了这一个博主的新文章提醒。一个新发现的公众号最近在朋友圈看到几次转发一个叫「线上又炸了」的公众号。写 Java 后端和中间件实战的风格比较实在每篇文章背后都是真实线上的踩坑复盘。讲真不做作。我看了几篇一篇写他们线上 RocketMQ 消费者假死的排查过程从现象描述到日志分析到根因定位全程没有废话。还有一篇写 MySQL 死锁的不是那种什么是死锁的科普而是直接上死锁日志逐行解读两个事务怎么撞上的。新号内容还不多但质量稳目前我放在有更新就看的列表里。这种公众号可遇不可求。大号的编辑要追热点要冲 KPI写出来的东西容易注水。小号反而因为没有商业化压力内容更纯粹。等它做大了会不会变不好说先看着。两个播客代码时间。国内少有的硬核技术播客主要聊后端架构和工程实践。节目长度通常一个半小时左右适合通勤路上听。主播的技术功底不错嘉宾请的也多是真正在一线做架构的工程师。我比较喜欢他们不预设结论的聊天方式经常出现两个嘉宾对同一问题有完全不同的看法比那种一问一答的采访有意思。Teahour。老牌播客了虽然更新频率不如从前但往期内容里有很多宝藏。丁元英那几期聊架构演化的我反复听过三遍。现在的内容更偏向创业和职业发展技术深度不如早期但视野更宽。如果你已经过了纯学技术的阶段开始思考技术跟业务跟人的关系Teahour 的后半段内容反而更有价值。三条筛选原则三年下来我总结的三条信息源筛选原则看作者不看平台。同一个平台好作者和烂作者的差距比跨平台还大。不要因为掘金质量下降了就不看掘金也不要因为InfoQ 是高端媒体就全盘接收。盯人不盯平台。有场景的有价值。Spring Boot 3.0 新特性详解这种内容如果你没有升级需求看了等于没看。真正有用的信息源是那些能跟你当前工作场景对上的——你在做消息队列选型那写 MQ 实战的就是好内容你在排查线上问题那写踩坑复盘的才是好内容。信息源好不好取决于你当下在做什么。更新频率不等于质量。我退订了好几个日更的公众号关注了两个周更甚至月更的。日更的作者大概率在凑数月更的作者每篇可能磨了一周。技术内容的消化速度远远慢于生产速度追更新频率是给自己制造焦虑。最后一句话信息源不是越多越好是你能消化多少才算数。我现在的 6 个信息源每个每周大概花 5-10 分钟扫标题挑 1-2 篇精读总共控制在 40 分钟以内。超过这个时间不是信息源的问题是你在用看技术文章逃避真正该做的事。