十年学习记录

整理旧资料时，我找到一批从 2014 年开始写的学习笔记，最早记的是实习时遇到的 Nginx 配置、Laravel 用法和 Linux 文件权限，还有不少命令。那时知道得不多，接触到什么就想记下来。

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

先学会把事情做出来

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

刚开始工作，今天学会的命令明天可能就用得上，读懂框架里的某段代码，也可能少踩一个坑。那几年从 JavaScript、MySQL 到 Nginx 和 Docker，笔记里什么都有。

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

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

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

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

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

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

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

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

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

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

搜索和问答工具方便了，很多资料不必再搬进笔记，工作熟悉以后也容易觉得自己已经理解，不需要专门写下来。

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

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

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

不过按年份翻一遍，仍能看出自己当时在做什么，后来又开始关心哪些问题。

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

这批旧笔记暂时留着，通用资料不必全部搬出来，有具体经历的部分再慢慢整理。