十年学习记录

整理旧资料时，我找到了一批从2014年开始保存的学习笔记。

最早的内容来自实习。里面记着如何配置 Nginx、怎样使用 Laravel、Linux 文件权限是什么意思，也记着一些现在看来已经没有必要保存的命令。那时接触到的东西几乎都会被写下来，知道得不多，记录得却很勤快。

这些笔记一直写到2023年。单篇内容大多谈不上完整，有些只是一个链接，有些是几段复制下来的说明。不过把它们按年份放在一起，仍然能看出我的工作和学习是怎样变化的。

先学会把事情做出来

2014年至2016年，我主要使用 PHP，也接触前端、数据库和服务器运维。学习通常从眼前的问题开始：框架怎么用，服务怎么部署，SQL 为什么慢，缓存如何配置。

刚开始工作时，知识的价值很直接。今天学会一个命令，明天可能就会在服务器上用到；读懂一段框架代码，接下来便能少踩一个坑。因此，那几年的笔记范围很散，从 JavaScript 到 MySQL，再到 Nginx 和 Docker，什么都记。

这种学习方式并不系统，却很符合当时的处境。先把问题解决，再逐渐补齐对问题的理解。很多工程师的起点大概都是如此。

2017年转向 Java 以后，笔记里的问题明显变了。

线程池为什么这样设计，垃圾回收器如何工作，索引为什么能提高查询速度，分布式系统怎样处理一致性。相比记住一个配置项，我开始花更多时间了解配置背后的机制。

2018年至2019年，这种倾向更加明显。那段时间关注 Java 探针、字节码、JIT、堆外内存和性能诊断，也研究过监控系统和一些中间件。工作中遇到的系统更大，问题不再总能靠搜索一条命令解决。只有理解调用链路和运行机制，才知道应该从哪里开始排查。

学习也从“以后可能有用”变成了“当前问题要求我继续向下追”。这是两种不同的动力。前者容易积累大量知识点，后者更容易形成真正属于自己的经验。

2020年以后，纯技术记录开始减少。笔记里逐渐出现架构设计、技术评审、跨团队协作、项目推进和述职表达。

这并不是因为技术问题变少了，而是工作中的困难已经不只来自代码。一个方案能否落地，还取决于需求是否清楚、边界如何划分、上下游是否达成一致，以及项目出现变化时由谁做决定。

过去我容易把复杂问题理解为技术问题，后来才发现，很多故障在写代码之前就已经埋下了：信息没有同步，目标并不一致，临时方案没有退出计划，或者所有人都默认会有别人补位。

技术仍然重要，只是它不再是解释所有问题的唯一视角。

2021年之后，按月记录的内容明显变少。到2023年，全年只剩下几条与 AI 有关的笔记。

一方面，搜索和问答工具让获取信息变得更快，不必再把每项知识搬进自己的笔记；另一方面，工作越熟悉，越容易觉得很多东西已经理解，没有必要专门写下来。

现在回头看，这两种理由都只对了一部分。

资料确实不必重复保存。大量旧笔记只是外部内容的副本，几年以后既没有继续使用，也很难确认是否仍然准确。但如果完全停止记录，消失的不只是资料，还有当时为何关注它、如何理解它，以及后来怎样修正判断的过程。

十年间使用过的框架和工具已经换过很多轮。早期认真记录的一些技术，如今甚至很少再被提起。如果只从知识是否仍然有效来看，这批笔记的大部分内容都可以删除。

但它们还保存了另一件事：一个人如何从掌握工具开始，逐渐理解系统，再把注意力转向工作中的协作与判断。

以后我不会再按照从前的方式保存所有知识。查得到的资料不必搬运，未经消化的内容也不急着整理成文章。真正值得写下来的，是一个问题为什么会发生，我曾经怎样判断，事实又怎样改变了这个判断。

这些内容未必比技术知识更正确，却更难从别处找到。