2026 年，人人都在刷短视频，我为什么反而搭了一个自己的博客？
短视频与 AI 让信息获取和内容生成越来越快，但记录、判断与长期可控的数字空间反而更珍贵。本文结合当前 Spring Boot 博客的真实架构、公开故障复盘与维护经验，解释我为什么仍愿意搭建并维护一个属于自己的个人博客。
晚上十一点多，我本来只是想看五分钟手机。
打开一个视频。下滑。再打开一个。再下滑。AI、科技新闻、游戏片段、一个讲得很漂亮的生活技巧、几段不知道为什么会被推到眼前的搞笑内容，像一条没有尽头的传送带。等我抬头，已经过去一个小时。
信息当然很多。可把手机扣在桌面上以后，我忽然很难说清：这一小时里，究竟有什么真正留了下来？
随后我打开自己的博客。这里没有播放量跳动，没有点赞动画，也没有一个系统替我决定“下一篇你应该看什么”。它可能一天只有很少的访问者，却保存着我解决过的问题、踩过的坑、学会的技术，以及当时为什么会那样想。
# 2026 年，人人都在刷短视频，我为什么反而搭了一个自己的博客？
这不是一篇“如何三分钟搭站”的教程。恰恰相反，我想谈谈一个更慢的问题：当所有平台都在努力让我们多停留一会儿、多刷一条时，为什么还会有人愿意维护一个访问量并不大的个人网站？
## 短视频真的很好
先说清楚：我并不讨厌短视频，也不会假装自己从来不刷。它非常强大。过去要搜索半小时、翻几页文档才能建立起的基本概念，现在常常能在一分钟的讲解里先获得轮廓。它降低了学习门槛，压缩了传播成本，让更多普通人拥有表达渠道，也让优秀创作者更容易被发现。
复杂知识可以先被讲得直观，这是一种进步。
真正值得问的不是“短视频好不好”，而是：**它适不适合承载我们所有的信息、所有记忆和所有思考？** 一个六十秒视频很适合让我知道某件事存在，却未必适合保存一个问题完整的来龙去脉；它擅长点燃兴趣，不必然擅长留下可检索、可引用、几年后仍能读懂的记录。
## 内容无限之后，什么更稀缺？
2026 年，生成内容已经不再是一件稀有的事。AI 能协助写文章、出图、做视频、写代码、整理资料和制作演示。这里并不需要编造一组夸张的增长数字来证明变化：只要打开任何内容平台，就能感到供给在加速。
*图 1：概念示意，并非统计数据。内容供给快速扩张，而人的时间并没有同步增加。*
以前更常见的困难是“找不到内容”；现在更常见的困难是“内容太多，不知道该把注意力交给谁”。当文字、图片和视频都可以被快速生产，变贵的反而是另一类东西：真实经历、长期积累、个人判断、能回到现场的过程，以及经得起时间复查的记录。
这也是我想写博客的第一个原因。不是为了和内容洪流比数量，而是为一些不应该被下一次下滑带走的东西，留一个位置。
## 从“我去找”到“它推给我”
推荐算法带来的便利真实存在。它能在我没有明确搜索词时，把可能感兴趣的东西送到面前；它也让创作者不必只依赖熟人转发。但是，便利改变了信息路径。
以前的互联网更像是：我有一个问题，打开搜索，挑选网站，阅读和判断。现在越来越多的时间则是：平台根据已有行为猜测兴趣，推来内容，我滑动，再给出新的反馈。
两条路径没有谁应该被消灭。问题在于，如果后一条路径占满了时间，主动寻找信息的肌肉会慢慢变弱。博客对我来说像一个刻意保留的反方向：我必须先想清楚标题，决定写什么、删什么、引用什么；读者也必须自己走进来，按自己的速度阅读。
## 我想拥有一小块“数字土地”
我把社交平台账号理解成租住的空间。房子很好：有水电、有邻居、有成熟的门禁和人流；但楼怎么改、房间能否继续使用、哪些内容被看见，最终由平台规则决定。
个人网站更像自己的房子。这个比喻不能说得太满——域名要续费，服务器可能迁移，托管商也会有规则，代码和数据库还要备份。它从来不是一句“绝对属于我”就能解决的事。可至少，域名、源代码、数据库备份、文章原文与页面设计可以被拆分掌控，并尽量保持可迁移。
所以，我搭建博客不只是为了拥有一个网址，而是为了拥有一个长期可控的数字空间：想写什么由我决定，文章如何组织由我决定，数据保留多久、怎样备份也由我承担责任。
**你现在正在阅读的这个网站，本身也是这篇文章的一部分。** 它不是一个抽象例子；这篇文字、这张封面、文章列表和可以回到的地址，正是“自己搭一个博客”最终变成现实之后的结果。
这里的“可控”并不意味着不用依赖任何人。一个域名要依赖注册商，服务器要依赖基础设施提供商，邮件和对象存储也可能依赖第三方。真正重要的是把依赖看清楚：域名能否转出，文章原文有没有副本，数据库是否能导出，图片是否有本地源文件，代码是否在自己的仓库里，恢复流程是否真的被演练过。
控制权不是一个开关，而是一组可以逐步改善的能力。刚开始时，也许只是把 Markdown 和图片放进一个有版本记录的目录；以后可以增加异地备份、监控、迁移文档和更明确的发布流程。它不必一夜之间变成“完全独立”，只要比“账号没了，一切都没了”多几层选择。
同样，自己的博客也不应该把读者困在里面。好的数字土地不是筑墙，而是给内容一个稳定的原址：链接可以被分享，文章可以被搜索，读者可以从平台来到这里，也可以从这里再回到别处。对我来说，独立站与开放互联网并不矛盾；它更像一个可靠的原点。
## 这个博客到底是怎么来的？
从浏览器看，博客只是一个首页、一列文章卡片和一个详情页。可这个项目并不是静态 Markdown 站点：它是一套 Java 8 的 Spring Boot 应用，使用 Spring MVC 和 MyBatis 读取 MySQL 中的文章；正文以 Markdown 保存，再由 Editor.md 在详情页渲染。首页封面也不是一个单独的数据库字段，而是从正文里第一张有效图片提取出来。
*图 2：当前项目真实首页截图。它不是生成的 UI 概念图。*
*图 3：根据当前项目结构绘制的简化架构。为安全起见，图中不包含主机地址、账号或密钥。*
请求先来到浏览器，经过 Nginx，再转给 Java 应用；应用读取文章、分类、标签和访问计数等数据。Git 保存代码历史，备份帮助内容在意外发生后回到可用状态。Codex 则在开发和维护过程中协助理解项目、查找改动范围、生成初稿、检查代码或分析问题。
这套系统不大，却让我第一次非常具体地理解：浏览器里看似简单的一篇文章，背后其实是内容模型、模板、静态资源、数据库、网络服务和维护流程共同完成的。
也正因为有这层真实结构，写文章不只是按下“发布”。标题需要避免和历史文章重复；分类尽量复用已有的名称；标签不能为了显得丰富而制造一堆同义词；封面要放在正文第一张图片的位置，才能正确出现在首页卡片里。图片上传以后还要检查 URL 是否公开可读、响应是不是图片类型、手机上会不会横向溢出。细节有点琐碎，但它们让文章不是“某次编辑器会话里的文本”，而是一条真正能被网站稳定读取的记录。
我很喜欢这种具体感。它把“个人表达”落在了工程事实之上：一段 Markdown 会进入数据库，一张图会进入静态资源服务，一条链接会在首页、详情页和搜索入口之间流动。读者看到的是排版；作者要关心的是它在下周、下个月是否还会显示正确。
## 拥有，也意味着维护
自己的博客不是“买一台服务器，上传文件，然后结束”。它会冒出很多很小、也很真实的问题：页面是否适合手机？一张封面会不会太大？图片地址会不会失效？HTTPS 到期怎么办？日志里出现的告警是否影响读者？备份能不能真的恢复？搜索引擎能否正确理解文章？
这个项目里确实有过一次公开复盘的故障：表面上网站返回 502，排查不能只盯着 Nginx。沿着反向代理、Java 进程、应用监听端口、系统日志和内存状态往下看，才找到“内存压力触发 OOM，Java 服务退出，Nginx 才无法连接上游”的链路。完整过程已经保留在这篇文章里：[一次真实的服务器故障排查：从 Nginx 502 到 OOM、Swap 与 systemd 守护](/article/1789288493)。
这类经历让我对“拥有”有了更朴素的理解：它不是控制一切，而是知道出了问题时，自己有责任理解、验证、修复或恢复。维护不应该抢走写作本身，但它让这个空间更可信。
这也解释了为什么我不愿意把博客写成一份炫耀技术栈的清单。Nginx、Java、MySQL、Git、HTTPS、SEO 这些词本身没有浪漫色彩。真正有意义的是，当页面突然无法打开、当图片加载失败、当一个旧链接被人点开时，我有办法顺着系统把问题缩小，而不是只能祈祷某个平台替我处理。
当然，维护也要求克制。生产服务不是练手场：排查可以先做只读检查，日志和截图必须脱敏，真正会影响数据或服务的修改需要确认，备份和回滚不能只是口头承诺。拥有个人空间，不是获得随意折腾的许可证；它更像学会为每一次改动留下边界。
## 为什么不直接用现成平台？
当然可以，而且很多时候更合适。现成平台注册即用，不用碰服务器、数据库、部署和备份；它们有成熟的移动端体验、自带用户和传播机制。如果目标只是让更多人尽快看见内容，平台可能是更好的选择。
但我的目标除了传播，还有一部分是记录。
我希望几年后仍能找到：2026 年的我在研究什么，遇到过什么问题，最初怎么理解它，又是如何慢慢改正的。平台上的表达可以是入口，博客则更像一份公开的个人知识库。两者不冲突，甚至可以互相导流；只是我不想把唯一的存档放在一栋不由我管理的楼里。
## AI 反而让我更想拥有个人博客
这听起来有点矛盾。AI 一方面让内容更多、更快、更容易淹没彼此；另一方面，它也把个人建站里许多曾经令人望而却步的步骤拉近了。
以前，想到一个网站，往往意味着先学 HTML、CSS、JavaScript、后端、数据库、Git、部署和排错。现在 AI 或 Codex 可以帮助我读懂陌生项目、定位模板、解释日志、生成图像初稿、检查改动和整理文档。它不能替我确认每一个结果，更不应该在没有边界时擅自改生产环境；但它的确让一个人有机会更早把想法做成可验证的东西。
有意思的是，这两件事同时发生：AI 增加了互联网内容的总量，也降低了普通人建立自己数字空间的门槛。
因此真正的问题没有变成“AI 能不能帮我写”，而是“我到底想留下什么”。工具可以帮助执行；网站的语气、内容标准、哪些经历值得诚实地写下来，仍然必须由人决定。
## 没有流量，还有意义吗？
一条短视频十万播放，一篇博客一百次阅读，前者一定更有价值吗？不一定；反过来也不一定。它们回答的是不同问题。
短内容可以快速抵达更多人，形成及时的交流；一篇博客则有机会在半年后被搜索到，在两年后被引用，或者在我自己再次遇到同一个问题时救我一次。我喜欢把这叫作长尾价值：不是每一次发布都在当天达到峰值，而是内容仍有机会在未来重新被找到。
*图 4：概念示意，并非统计数据。它不比较高低，只说明不同媒介可能拥有不同的生命周期。*
一篇技术记录也许没有即时热度，却可能让一个陌生人少走半天弯路；也可能让未来的我想起，当时为什么要这样配置、为什么拒绝那个看似简单的方案。这个价值很难被实时数据完整衡量。
搜索在这里扮演的角色也很特别。推荐流常常把内容送到“可能感兴趣”的人面前；搜索则往往发生在一个人已经遇到具体问题的时候。前者适合发现，后者适合解决。博客不保证一定排到前面，也不保证每一篇都会被索引，但它至少保留了被再次发现的可能：一个清楚的标题、一段可复制的步骤、一张说明结构的图，可能在很久以后仍然有用。
我也不想把“流量少”包装成某种道德优越。阅读量是反馈，认真写作者当然会在意。只是当唯一指标只剩当日播放和即时互动时，许多需要慢慢形成的内容会显得不合算。博客给我的，是允许这些“不够即时”的内容存在。
## 我真正想记录的是什么？
未来这个博客可能会继续写 Java、Linux、Git、AI、项目开发、工具使用、服务器踩坑和解决问题的过程。也会有一些暂时还没有结论的思考。
不是为了证明我懂很多。
而是为了把我曾经不会，后来弄懂了的过程留下来。
过程比结论更诚实。结论很容易被一行摘要替代，过程里却有判断、失败、证据、条件和当时的限制。它既能帮助别人，也提醒我：很多今天理所当然的能力，都是从某个具体、笨拙的问题开始的。
我希望这个地方能保留一些没有被剪成爽点的时刻：一次排查走错方向后为什么回头，一次页面改版为什么保留旧入口，一次 AI 生成的方案为什么没有直接采用。它们未必适合做成一条吸引注意力的视频，却很适合写进一篇可以被慢慢读完的文章。多年以后，答案可能不再重要，当时的判断路径仍值得回看。
这也是公开写作和私人笔记之间让我着迷的距离。它不是完全私密的日记，所以我会尽量把背景、边界和事实说清；它又不是只为迎合陌生人的内容产品，所以我允许自己保留长一点的铺垫、必要的犹豫和暂时没有结论的问题。它像一个对外开放的工作台：能被别人看见，也能被未来的我使用。
## 也许 2030 年，我会回来读今天这篇文章
到了 2030 年，今天谈论的 AI、Codex、短视频、服务器和博客，可能都已经变样。某些工具会过时，某些接口会消失，今天觉得先进的工作方式也许会变得普通。
但文章还能告诉未来的自己：2026 年时，我是怎样理解互联网的；为什么开始维护这个站；在学什么；又相信什么。
时间感是我舍不得放弃博客的另一个原因。很多平台上的内容是为“此刻”设计的：今天的热点、今天的情绪、今天的节奏。它们当然有价值，却很少鼓励我在几年后重新翻页。博客的归档、分类、标签和固定链接看起来有些老派，恰好因此适合抵抗遗忘。它们不保证记忆永远准确，却能给记忆一条回去的路。
而且这条路不必宏大。它可以只是一个普通的周末、一次解决问题后的复盘、一段后来重新读起仍觉得有用的说明。
我也希望未来的自己能看见不完美的版本。也许某个判断后来被事实推翻，也许一段技术方案已经过时。保留它们不是为了证明当时总是正确，而是为了知道自己怎样改变。一个可以修订、可以补充、也保留发布时间的个人站点，比一串被新内容覆盖的动态，更适合承载这样的变化。
博客最终不仅是一个 Website。它也可以是一条 **Timeline of Myself**——不是精修过的个人品牌页，而是一条允许变化、允许承认不知道、允许慢慢长出来的时间线。
手机仍然在那里。短视频仍然很好看，算法也会继续推荐下一条内容。我不会因此停止刷视频。
但是，在互联网的某个角落，还有一个地址。那里没有算法决定我的下一篇文章是什么，也没有要求我必须在三十秒内抓住注意力。我可以写一千字、三千字，甚至八千字；只要我认为这件事值得留下。
**也许搭建个人博客并不是在和短视频时代对抗。**
**我只是想在一个越来越快的互联网里，给自己留下一个可以慢一点的地方。**
**这里，就是我的博客。**
