2024 年的代码比前一年多了很多，但比起仓库数量，我更愿意记住开始问“下一次谁来维护”。
网络笔记把请求拆成 DNS、连接、协议和应用，Docker 让依赖、端口和数据被写进文件，缓存学习则让我看到速度背后的失效策略。它们本来是不同课程和项目里的知识，放在一起以后，逐渐变成同一个问题：系统在正常之外怎样继续工作。
博客是这条线最具体的练习。页面、反向代理、API、数据库和域名连在一起，任何一层出问题都可能被误以为是“网站坏了”。我开始保存配置和备份，也开始知道一条 200 响应不能证明文章已经正确写入。读回、日志和回滚比一次成功部署更值得记录。
课程作业仍然会结束，代码却可能在仓库里留很多年。把构建命令、依赖版本和运行方式写进 README，是为了让未来重新打开时少猜一点。更多时间其实花在把旧功能重新跑起来：确认锁文件没有漂移，检查环境变量是否仍然存在，再把一条最小请求走通。
这一年我也开始记录“结果之外”的状态。一次接口返回 200，只能说明这次请求被接受；一次构建成功，也不代表生产环境的迁移和静态资源没有问题。把检查拆成几个小步骤以后，很多原本模糊的故障都有了落点。它们不一定立刻被修好，但至少不再只能靠重启碰运气。
这一年也让我对“架构先进”多了一点警惕。服务拆得越细，环境、网络、事务和部署的成本越高；工具越多，越需要知道它们各自解决什么问题。对个人项目来说，能恢复、能解释、能继续改，通常比一张复杂的架构图更重要。
2024 没有一条漂亮的直线，只有很多次把报错翻译成下一步动作的过程。它把我从“把功能做出来”推向“把系统照看下去”，这大概是这一年最可靠的沉淀。
这一年最实际的收获是知道什么时候停下来。一个小项目如果没有用户、没有数据和没有维护者，就不必为了架构完整继续加服务。把边界收小以后，剩下的代码反而更容易被验证。删掉一条没有必要的依赖，有时比再写一个功能更像进步。
我开始把部署看成一条需要反复走的路径，而不是一次性的终点。构建命令、环境变量、数据库迁移、静态资源和回滚版本都应该能被单独检查；其中任何一项只能靠“我记得”来完成，下一次维护就会变成重新试错。
个人项目没有专职运维，反而更需要把边界写小。能用一个进程解决的问题，不必先拆成几个服务；必须拆开的部分，则要留下健康检查、日志和恢复动作。可维护关键在于让每个选择都有一个下次还能执行的理由，架构不必因此变大。