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

工作三年多时，我经常听到别人说业务代码没有技术含量。重复实现相似功能，确实不会自动带来能力增长，但问题未必在业务本身，也可能是完成需求之后，没有继续追问系统为什么这样运行。

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

系统学习

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

系统学习不必从头背完一本书，可以先理清核心概念之间的关系，看看哪些机制会影响当前工作，哪些地方自己还无法解释，再用文档、书籍和源码补足细节。

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

动手验证

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

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

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

把问题讲清楚

把问题讲给别人听时，许多原本可以含糊过去的地方就绕不开了，需要解释概念的边界、结论依赖的条件，以及判断的依据。

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

回到业务现场

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

我当时总结的这三个动作，还是得放回工作里去做。遇到具体问题，学习相关机制，用小实验验证判断，再把结论写清楚，看看能不能用在实际系统里，避免功能做完了，学习也就停了。