本文最初写于2017年，2026年重新整理。

工作三年多时，我开始反复听到一种说法：业务代码没有技术含量。它说中了一部分事实——重复实现相似功能，确实不会自动带来能力增长；但问题未必在业务本身，也可能在于我们只完成了需求，没有继续追问系统为什么这样运行。

当时我把技术学习归纳成三个动作：Learning、Trying、Teaching。多年后再看，这个结构仍然有效，只是它们不应该彼此分离。

系统学习

搜索和短文章适合解决一个明确问题，却很难独立建立完整认识。操作系统、网络、数据库和运行时这类基础内容，仍然需要相对系统地学习。

系统学习不等于从头背完一本书。更实际的方式是先建立问题地图：核心概念之间是什么关系，哪些机制会影响当前工作，哪些地方自己还无法解释。之后再用文档、书籍和源码补足细节。

学习的结果不应只是收藏更多资料，而是能用自己的语言说明一个机制及其适用边界。

动手验证

很多技术概念在实际运行以后，更容易暴露理解上的空白。

例如学习JVM垃圾回收，可以写一个持续分配内存的小程序，调整参数，再观察堆、停顿和回收日志；学习Reactor，可以先实现一个最小事件循环，再对照成熟框架如何处理线程和连接；学习数据库，可以从慢查询、索引和实际执行计划出发，而不是只记住几条优化原则。

验证不一定需要完整项目。一个能够证伪自己判断的最小实验，往往比照着教程搭建一套复杂环境更有效。

把问题讲清楚

当一个人需要把问题讲给别人听时，会被迫处理很多原本可以含糊过去的地方：概念的边界是什么，结论依赖什么条件，别人为什么应该相信。

这里的“讲”不一定是公开演讲，也可以是一篇文档、一次设计评审或给同事解释故障原因。反馈会暴露遗漏，反过来推动下一轮学习和验证。

回到业务现场

技术成长不能长期停留在模拟环境。更复杂的部分通常来自业务约束：数据不能停、上下游不可控、团队需要协作、方案还要考虑成本。

因此更完整的循环应当是：从工作中发现具体问题，系统学习相关机制，用最小实验验证判断，再把结论写清楚并带回实际系统。业务不是技术成长的障碍，它提供了问题和约束；是否继续深入，取决于我们有没有停在“功能已经完成”这一步。