速读#
这篇是博客的起点，解释为什么要把折腾过程、踩坑路径和判断写在一个固定地方。它定下了后来所有文章的口径：不是资料搬运，而是写给半年后的自己看；更新也不靠日更 flag，而靠解决一个具体问题后顺手记录。
为什么开博#
你好，我是 s1oopX。这是这个博客的第一篇文章，写在 2025 年的深秋。开博的理由其实很简单：我折腾的东西越来越多，而脑子越来越不够用。上个月刚把一个 Django 练手项目推到 GitHub，写完 README 的时候突然觉得——光有代码不够，过程里踩的坑、试错的路径，没地方留。
笔记我不是没记过——散在四个 app 里，格式乱七八糟，自己都不想翻。后来想明白，笔记的问题不在工具，在它允许我烂尾：贴个链接、截张图、写半句话，都算「记了」。公开发出来不一样，一篇文章得把前因后果交代完整才能见人。这个「必须讲完整」的压力，正是笔记给不了的东西。
这里会写四类#
- AI：我把什么交给了 AI、边界划在哪。不是「怎么用 AI」，是我用半年形成的规则和栽过的跟头。
- 技术：后端代码（先是 Python，后面碰了 Java）、服务器折腾、Linux、Docker、部署运维。这篇主线是「我怎么复盘的」，不是教程。
- 推荐：我在某个长期需求上固定用哪个工具、为什么。每条四要素：用途 / 选它而非什么 / 用了多久 / 会不会换。
- 日常：和代码有关或无关的碎念——debug 的玄学、学习方法、年终总结。不会太多，但偶尔需要。
我给自己定的调子是：写给半年后的自己看。所以会保留可复现的命令、关键配置、原始错误和验证结果，而不是只写结论；令牌、域名后端、个人数据和内部地址必须替换或脱敏，示例还要标明适用版本。比如配 Nginx 时，我会把 proxy_pass 末尾有没有斜杠如何改变 URI 写清楚，因为半年后我一定还会忘。重点不是“我知道什么”，而是“问题是什么、我怎么判断、最后在哪些条件下验证通过”。
这个口径还有个附带的好处：它替我过滤了选题。「XX 入门」这类东西别人写过一百遍，轮不到我再写；但「我在这一步卡了四十分钟、最后发现原因是什么」，这种只有我自己能写。写不写得出后一种，顺便也检验了我到底有没有真的经历和思考。
为什么自己搭#
市面上现成的写作平台很多，但我还是想自己搭。一来是把“搭博客”本身当成长线练手项目，从主题、部署到上线，每一层都能形成真实反馈；二来是希望内容有清晰的导出和迁移路径。开博时使用自托管 WordPress，文章在数据库、图片在服务器，备份和恢复都要自己负责；“在自己手里”不等于天然安全，只有异机备份和恢复演练做成了，所有权才不只是一句心理安慰。
自己搭还有个隐性收益：这个站就是我的第一个生产环境。它真的在线、真的会被访问，配置错了会挂，升级也可能失败。拿自己的站练手比教程示例逼真得多，但恢复上一版、还原备份和临时切维护页同样是修复手段；生产意识不是硬扛到现场改好，而是先恢复服务，再保留证据找根因。
2026 年 8 月注： 站点后来从 WordPress 迁到 Astro，文章、图片和配置改由 Markdown 与 Git 管理，CI 验证后再通知 VPS 构建独立 release、健康检查并切换。技术栈变了，开博时真正想守住的东西没有变：内容可导出、发布可回退、故障能解释，工具服务于持续写作，而不是反过来绑住内容。
工具的意义，是让你愿意持续地做一件事。一个自己喜欢的博客，就是让我愿意持续写下去的工具。
关于更新节奏#
不立每天更新的 flag，那种 flag 我立过，没有一次活过一周。我的节奏是：解决一个具体问题、想清楚一件事，就记一篇。门槛够低，才扛得住长期。
也提前跟自己说好：允许写得糙。一篇几百字的「问题—排查—结论」，只要把过程留下了，就比一篇憋了两周还没发出来的完美长文有用——后者大概率永远不会被写出来。
那么，就从这里开始吧。