速读#
这是博客上线 241 天后的阶段复盘，核心变化是从「写完代码」走到「交付一个真正可用的东西」。39 篇文章串起来后，主线不再是技术栈变化，而是「知道」和「经历过」之间的差距，以及按系统分面看问题的习惯。
核心变化#
大半年前我觉得「写完代码」就结束了。现在我知道，代码只是开头——怎么让它稳稳地跑在别人能访问到的地方，才是更长的一段路。
从 Python 接口到 Cloudflare Tunnel，本质上是从「写功能」到「交付一个真正可用的东西」。这句话我现在能给它配上具体的图景：一个请求从浏览器出发，要过 DNS、边缘防护、隧道、反代、应用、数据库，再原路回来——这条链上每一层都是我亲手搭的零件。「交付」不是虚词，是这一整条链都站得住。
这个变化不是哪天想通的，是被一次次具体的失败推着走的：接口本地跑得好好的，上线就 502；进程半夜崩了，没人拉起来；日志里每天几百条陌生 IP 的扫描。每处理掉一次，链条上就多一环真正归我管的零件。回头看，认知是失败垒出来的，不是文章读出来的。
知道 vs 经历#
这次整理 39 篇时我给自己定了条标准：文章的重点不是「我知道什么」，是「我经历了什么、我怎么判断、最后形成了什么理解」。去掉「我」如果变成谁都能写的资料，就不合格。
对照这点回看，写 YouTube 架构那篇差点踩线——讲大厂架构，本质上是谁都能查的资料。最后我把它改成「照镜子」：照我这套小站差距在哪、哪些该补、哪些不该碰。「我」进去了，它才从资料变成理解。
这个判断反过来也成立：好几篇我自己回头看还觉得有用的，恰恰是因为它们记录了真实的决策过程。不是「Docker 有三大优势」，而是「我为什么从 venv 迁移到 Docker、迁移过程中哪个命令差点删光我的数据」。具体错误比正确结论值钱。
几条贯穿 39 篇的体会#
这几条不是这次总结才想出来的，是这 39 篇里反复出现的：
- 环境问题占了我所有 bug 的一大半——从 venv 到容器，都是在治「环境不一致」这件事。venv → Docker 是同一条「隔离」线在不同粒度上的两次落地。
- 安全不是最后才想的事——SSH 密钥、防火墙、零暴露端口（Tunnel），越早做越省心。防护是分层的，越早分层越省。
- 不靠「我记得」，靠「系统兜底 + 我验证过」——systemd 拉进程、certbot 续证书、fail2ban 封 IP，同一范式：人制定规则并验证，机器执行。不是「设好就不管」，是「设好之后定期确认它确实在工作」。
- 写下来，是我留住这些的唯一办法——这条从年终总结那时就在验证：门槛够低才扛得住长期。39 篇没有一篇是「为了更新而更新」，全是解决了一个问题顺手记的，这个节奏反而没断过。
这些体会串起来，其实是一套工作流分面：可达/守护/防护/可观测/配置密钥/变更/数据/运维入口。半年前我连「分面」这个意识都没有，现在加一个新服务会按面过一遍——这是最大的认知变化。
接下来想去哪#
- 分布式那条线，该补的两条小 demo（多副本、消息队列）动手试——不追大规模，补理解缺口；
- 把「按面检查」从习惯变成清单：新服务上线前，可达、守护、防护、可观测各面过一遍，别靠临场想起；
- 保持节奏：解决一个问题，记一篇。
从写代码到玩服务器，变的是技术栈，不变的是那点「想把它彻底搞明白」的劲儿。241 天、39 篇——这股劲儿是真的。