搭建技术博客时，最容易被低估的一步是分类。
我最初的想法很朴素：把打算写的东西列出来 —— IT 运维、网络、虚拟化、操作系统、手机、数码、装机配置、硬件评测、软件推荐、转载、存档，一共 11 个方向。一个方向开一个分类，齐活。
真开始建的时候才发现，这 11 个东西根本不是同一种东西。
一、不是所有内容都该长在同一棵树上
我的博客用 Halo 搭建，主题是「源蝶文档」。这个主题有个机制，逼着我在建分类之前先想清楚一件事：
你勾选为「文档组」的一级分类，它下面的所有子分类会被渲染成左侧常驻导航树。文章挂在这棵树下，就是「文档」形态 —— 左边有目录树，右边有本页大纲，底部有上下篇翻页。不在这棵树下的，走普通博客的归档和标签流。
换句话说，分类树就是文档的骨架，它不是简单的标签聚合。
这就引出一个必须回答的问题：「某款 SSD 开箱」和「PVE 虚拟机网络不通怎么排查」，要不要放在同一个分类下？
前者你写完就不看了，读者刷到就看、读完即走；后者你会翻一百次，读者是带着报错搜过来的。把它们塞进同一棵树，导航会越来越乱，最后谁都找不到东西。
我把这两种内容分别叫常青文档和时效博客：
| 常青文档 | 时效博客 | |
|---|---|---|
| 读者行为 | 带着问题来查，反复回访 | 刷到就看，读完即走 |
| 生命周期 | 会持续修订 | 发布即定格 |
| 典型内容 | 排查手册、命令速查、配置单、装机清单 | 评测、开箱、转载、日常吐槽 |
| 页面形态 | 左侧目录树 + 右侧大纲 | 归档页 / 标签页 |
想明白这一层，分类就不是「把方向列出来」，而是「把内容分流」。
二、分流三问
写每篇文章之前问自己三个问题，多数答「是」就进文档组：
- 半年后我还会翻出来查吗？
- 它会随版本 / 行情持续修订吗？
- 读者是带着报错来搜的吗？
这三个问题比「这篇文章属于哪个领域」好用得多，因为它判断的是内容的寿命和用途，而不是主题。
拿「软件推荐」举例：一篇《2026 年装机必备软件清单》你会一直更新，答「是」；一篇《XX 输入法三个月使用体验》写完就定格了，答「否」。它们虽然都叫「软件」，但归宿完全不同。
三、最终的分类树
按这三问过一遍，最后落成 9 个一级分类，分成两组。
五个文档组（常青知识）
1. 运维实战手册 —— 按技术领域组织的系统性笔记，站点的主体。
- 桌面与终端支持（AD 域、账号权限、打印机外设、批量部署）
- 网络运维（VLAN、无线 AP、VPN、多子网、排障命令集）
- 系统与服务器（Windows Server、Debian/Ubuntu、服务调优、备份恢复）
- 虚拟化与容器（PVE / ESXi、Docker / Compose、存储与网络）
- 监控与告警（Zabbix、Prometheus、日志采集）
2. 故障案例库 —— 独立成组，不放在运维手册下面。
- 网络故障 / 系统与服务 / 虚拟化与存储 / 终端与外设 / 应用与中间件
3. 装机与硬件 —— 配置单会随行情更新，天然是常青内容。
- 配置单推荐 / 选购避坑指南 / BIOS 与固件 / 驱动与兼容性 / 拆机与维护
4. 软件工具箱 —— 只放清单和用法，不放单品评测。
- 装机必备清单 / 效率与生产力 / 自建服务与 NAS / 商业软件替代
5. 数码玩机 —— 玩机教程常青，开箱评测不是。
- Android 玩机 / iOS 与苹果生态 / 数据迁移与备份 / 智能家居与 IoT
四个普通分类（时效内容）
- 评测与开箱 —— 硬件评测、数码开箱、软件体验
- 转载与收藏 —— 他山之石与译文（必须标出处）
- 运维随笔 —— 今日踩坑、碎片经验、行业观察
- 存档 —— 旧站迁移、已弃用方案
四、11 个方向是怎么被拆开的
最花时间的一步，是发现有 5 个方向需要「一分为二」：
| 原来的方向 | 拆成 |
|---|---|
| IT 技术支持运维经验 | 成体系的进「运维实战手册」，碎片吐槽进「运维随笔」 |
| 网络运维 | 手册讲怎么做，案例讲怎么救 |
| 手机 / 数码产品 | 玩机教程进「数码玩机」，开箱评测进「评测与开箱」 |
| 软件评测推荐 | 清单进「软件工具箱」，单品评测进「评测与开箱」 |
| 电脑配置推荐 | 进「配置单推荐」，每篇标注「更新于 YYYY-MM」 |
一句话总结规律：「怎么做」和「我试了什么」必须分开。前者会沉淀，后者会过时。
五、两个反直觉的决定
故障案例库为什么不放在运维手册下面
直觉上，故障案例应该是运维手册的子分类。但我把它独立成了一级分类。
理由是检索路径完全不同：查手册的人想的是「我想学怎么做」，查案例的人想的是「我报错了快救命」。后者往往不记得自己该去哪个技术领域找，只记得现象。混在一起，两类读者都会多绕一圈。
案例的写法也建议统一：标题用 【现象】xxx —— 根因与解决，正文固定「现象 / 排查过程 / 根因 / 解决」四段。这样半年后你自己搜关键词也能一击命中。
存档为什么做成顶级分类
「存档」不是一个主题，它是一个状态。如果做成二级分类，它会到处长出来（「网络运维/存档」「虚拟化/存档」……）。做成顶级普通分类，只作为历史内容的兜底桶，干净得多。
同理，别用「2026」「10月」做标签 —— 博客自带归档页，时间维度已经有了。
六、标签别抢分类的活
分类是纵向骨架（稳定、少变），标签是横向切面（灵活、可增）。分工明确才不会互相打架。
我把标签分成四类，一篇文章打 3-5 个：
- 技术栈：
#PVE#Docker#Nginx#1Panel#Debian#AD域 - 品牌厂商：
#海康威视#Dell#H3C#群晖#Intel - 内容类型：
#速查表#故障复盘#配置单#踩坑#迁移 - 状态（自己管理用）：
#待验证#已弃用
反例：别建 #电脑 这种和分类重复的标签，也别建时间标签。
七、命名规范
| 项 | 规范 | 例子 |
|---|---|---|
| 显示名 | 中文 2-6 字，去掉虚词 | 用「故障案例库」，不用「故障案例相关的文章」 |
| slug | 英文小写 + 连字符，不超过 20 字符 | 用 build-list，不用 diannao-peizhi-tuijian |
| 二级 slug | 必须全局唯一 | 网络运维 network、网络故障 case-network |
| 排序 | 用分类自带的 priority 字段 | 别用「01-」「02-」前缀污染 slug |
八、冷启动：别一次建满 9 个分类
空分类是站点最劝退的东西 —— 点进去「暂无内容」，比没有这个分类还糟。
建议分三期：
- 第一期：运维实战手册、故障案例库、评测与开箱（3 个）
- 第二期：攒够 5 篇再开装机与硬件、软件工具箱、运维随笔
- 第三期：有历史内容再开数码玩机、转载与收藏、存档
判断标准很简单：一个二级分类下有 3 篇以上，再建它。宁可先把文章挂在父级下，也不要建一堆空壳。
九、八个坑
- 一篇文章只挂一个分类。 支持多分类不等于该用多分类 —— 一篇评测如果挂了文档组下的分类，会污染左侧导航树。
- 转载内容绝不进文档组。 它不属于你自己的知识体系，还带版权风险。
- 文档组别超过 6 个。 左侧树会又深又挤，移动端抽屉没法用。
- 改了主题配置要点「重载主题配置」，改模板必须重新构建上传。
- 别把「存档」做成二级分类。 它是状态，不是主题。
- 搜索需要额外插件。 页眉搜索入口没出现，通常是没装搜索插件，不是主题坏了。
- 正文必须用 h2/h3 分节。 否则右侧本页大纲不会生成。
- 配置单务必标注更新日期。 硬件行情变化快，读者最怕看到三年前的价格。
最后
回头看，分类这件事真正难的不是「想出分类名」，而是承认自己的内容有两种寿命。
一旦接受这一点，很多纠结就自动消解了：评测不用挤进文档树，转载不该占用导航位，随笔可以先随便放、攒够了再升级成正式文档。
如果你也在搭技术博客，建议先别急着建满分类 —— 拿这三个问题问一遍自己最近写的五篇文章，答案会比任何模板都准。