博客建完以后,我最该记住的不是主题配置
搭博客最容易让人误会的一点是:你会以为自己在做一个网站,实际大部分时间都花在“让自己别继续折腾网站”上。
这次我用 Hexo、Fluid 和 EdgeOne Pages 把 nmdft.cn 重新搭起来。技术上不复杂,但它提醒了我一个老问题:建站阶段最重要的不是把主题调到完美,而是尽快建立一套以后还能维护的内容和部署规则。
否则博客很容易变成一个漂亮的空壳:主题换了三轮,导航调了半天,最后文章没几篇,或者全是 AI 凑出来的流水账。
所以这篇不写成教程,只记录几个以后还会用到的选择。
为什么最后还是选 Hexo
我之前考虑过几种方案。
WordPress 功能完整,但对现在的我太重。数据库、后台、插件、安全更新,一整套东西都要维护。如果只是写个人技术/产品日志,没必要为了后台编辑体验背上这堆运维成本。
Hugo 很快,也很适合静态站。但我对 Node.js 生态更熟,Hexo 的主题和插件也更容易查。遇到问题时,我能直接看 npm 包源码,排查成本低一点。
最后选 Hexo,不是因为它最先进,而是因为它足够熟、足够稳、迁移成本低。
这类个人博客技术选型,我现在更看重三个指标:
| 指标 | 我的判断 |
|---|---|
| 能不能长期维护 | 比功能丰富更重要 |
| 出问题能不能自己查 | 比“看起来现代”更重要 |
| 写文章流程是否顺手 | 比主题炫不炫更重要 |
Hexo 正好满足这些要求。
为什么用 Fluid
主题试过 NexT、Butterfly、Fluid。
NexT 很经典,但视觉上偏旧。Butterfly 功能多,也更热闹,但有些功能对我来说反而会分散注意力。Fluid 的中文文档完整,配置项清楚,默认视觉也够干净。
最关键的是:它不逼我改太多代码。
主题这东西,够用就好。个人博客最危险的不是主题不好看,而是把时间全花在主题上。导航、分类、文章页、评论、统计这些基础项跑通以后,就应该回到内容本身。
我以后不想再为了“首页某个动效不够酷”浪费半天。
部署放到 EdgeOne Pages
部署选 EdgeOne Pages,原因很现实:域名和其他腾讯云资源已经在腾讯云体系里,国内访问速度也比 GitHub Pages 稳。
静态博客不需要 SSR,不需要复杂后端。EdgeOne Pages 自动构建、CDN 分发,足够了。
后来评论系统也用到了 EdgeOne Pages Cloud Functions,这让博客从纯静态站多了一点轻量交互能力:前端仍然静态,评论 API 放在函数里,数据库单独隔离。
现在这个结构比较清楚:
1 | |
对一个个人站来说,这个复杂度刚好。再往上加 CMS、后台、SSR,就要非常谨慎。
哪些配置必须写进文档
这次踩过的低级坑主要不是代码,而是配置靠记忆。
比如:
- Hexo 构建命令;
- EdgeOne Pages 的构建输出目录;
- Fluid 主题配置位置;
- 评论系统需要哪些环境变量;
- 哪些文件不能提交到仓库;
- 图片和文章素材应该放在哪里。
这些东西不写下来,下次迁移或重装时一定会再踩。
所以现在我更倾向于把项目里的维护信息放进 docs/:
docs/site-maintenance.md:站点维护和部署说明;docs/blog-comments.md:评论系统设计和环境变量;docs/blog-quality-guide.md:文章质量标准;docs/blog-writing-guide.md:写作流程和风格要求。
博客不是只靠源码维护的,也靠这些“下次别再想一遍”的文档维护。
真正该维护的是内容标准
建站折腾完之后,我最想留下的不是“我用了哪个主题”,而是内容标准。
这次回看旧文章,很多问题都很明显:有的太短,有的像 AI 自动总结,有的只是抱怨,有的方案阶段写得像已经完成,有的几篇都在讲同一个事。
这比主题配置重要多了。
网站结构没问题,文章质量不行,读者照样不会留下。反过来,主题朴素一点,只要文章有现场、有判断、有具体细节,就仍然值得看。
所以以后博客维护的重点应该是:
- 定期清理低质量旧文;
- 合并重复题材;
- 方案阶段和完成阶段要区分清楚;
- 每篇至少有一个具体可复用的信息;
- 不为了日更牺牲判断质量。
技术底座只是让内容能被访问。真正决定这个站有没有价值的,还是内容本身。
留给以后的自己
如果以后我又想重构博客,先问三件事:
- 这次改动会不会让写作更顺手?
- 它是不是解决真实维护问题?
- 如果不改,对读者有没有影响?
如果答案都是否,那就别动。
个人博客最怕的不是技术落后,而是永远在装修,永远不认真写。
这次建站真正要记住的,不是 Hexo 命令,也不是 Fluid 配置,而是这条底线:网站是容器,内容才是长期资产。别把容器当成项目本身。