从 Obsidian 到自建平台：我的个人知识库整体方案说明 #

写在前面 #

我希望搭建一套长期可维护的个人知识管理系统，用来承载编程学习、项目记录、过程复盘和对外发布内容。

这套系统不是单点工具，而是一条完整链路：

• 本地记录和整理
• 跨设备同步
• 版本控制
• 备份与容灾
• 文档发布
• 博客发布

在对自己的设备、服务器、NAS 和使用习惯做了梳理之后，我最终决定以 Obsidian 作为主入口，围绕它搭建一整套自建知识平台。

我的资源条件 #

当前我手上的基础资源如下：

• 一台阿里云服务器
• 一个可用的独立域名
• 一台本地 NAS：绿联 DXP4800 Plus
• NAS 可以通过阿里云服务器的内网穿透进行远程访问
• 主力设备包括：
  • MacBook Pro
  • Windows 电脑
  • Android 手机
  • Android 平板

我对这套系统的核心需求也比较明确：

• Obsidian 作为日常主写作工具
• 支持 Mac -> 云端 -> Windows 的一键同步流程
• 不要求实时同步，但需要可控的一键更新
• 本地知识库能够长期沉淀，不依赖单一平台
• 能把整理好的内容同步到 语雀
• 能继续扩展到自己的博客平台

为什么选择 Obsidian 作为主库 #

对我来说，Obsidian 最重要的价值不只是“记笔记”，而是它把知识库保存在本地普通文件里。

这意味着：

• 笔记本质上是 Markdown 文件
• 可以直接被 Git 管理
• 可以被脚本处理
• 可以被 AI 工具辅助修改和整理
• 后续迁移到语雀、博客或其他平台都更方便

如果只把笔记放在某一个在线平台里，短期使用很省事，但长期会受到平台能力、导出格式、自动化程度和内容迁移的限制。
而 Obsidian 作为“本地知识主库”更适合作为整个系统的根基。

为什么不用 NAS 直接当主工作盘 #

一开始我考虑过把 Obsidian 的 Vault 直接放在 NAS 上，然后所有设备都连接同一个共享目录。

但这样做的问题也很明显：

• 网络状态不稳定时，体验会下降
• 跨设备同时编辑容易出现冲突
• 远程挂载目录并不适合作为主写作盘
• 移动端和桌面端的行为会更加复杂
• 一旦共享权限或连接出问题，会直接影响主库使用

所以这套方案里，NAS 不作为主工作盘，而是作为：

• 备份节点
• 快照节点
• 镜像节点
• 辅助服务节点

为什么选择 Gitea 作为同步中转 #

我需要的不是“实时热同步”，而是：

• 在 Mac 上写完后，一键同步到云端
• 在 Windows 上打开前，一键拉取到本地
• 所有变更都能保留历史版本
• 整体流程可控、可回滚、可排错

这正好更适合 Git 的工作方式，而不是更复杂的实时同步系统。

我选择 Gitea 作为云端 Git 服务，主要原因是：

• 可以自建在阿里云服务器上
• 资源占用相对可控
• 适合个人或小规模使用
• 后续还能承接自动化构建和部署

为什么语雀和博客不直接承载全部原始内容 #

我希望同时使用 语雀 和自建博客，但它们不应该直接替代 Obsidian 主库。

原因很简单：

• 原始学习记录往往比较碎
• 有些内容只适合自己查阅
• 有些内容还没整理完成
• 有些内容并不适合公开

所以在这套系统里，我会把内容分成三个层次：

1. 原始记录：放在 Obsidian 里，包含学习笔记、随手记录和临时草稿
2. 整理后内容：仍主要在 Obsidian 中维护，但更适合复习、复用和再加工
3. 发布内容：只把真正适合公开阅读的内容送到语雀和博客

整体架构设计 #

我的知识库系统会按 5 层来设计：

• 内容层：Obsidian Vault、Markdown 文件、图片和附件
• 同步层：MacBook Pro、Windows、本地副本、Gitea
• 备份层：NAS 备份、快照和历史副本
• 发布层：语雀和博客
• 运维层：域名、HTTPS、反向代理、用户权限和自动化脚本

这套系统的预期工作流 #

当整套方案跑通后，我日常使用时大致会是这样：

1. 在 Mac 上用 Obsidian 写笔记、整理文章
2. 写完后通过 Git 一键同步到 Gitea
3. 在 Windows 上打开前一键拉取最新内容
4. NAS 定期备份仓库和附件
5. 从知识库中挑出适合发布的内容
6. 将发布内容同步到 语雀
7. 将公开内容同步到自建博客

结语 #

对个人知识管理来说，工具本身并不是终点。
真正重要的是，能否建立一条既适合自己、又能持续积累的内容生产链路。

这套方案的出发点很简单：

• 在本地安心写
• 在多设备之间稳定同步
• 在 NAS 上安全备份
• 在语雀和博客上持续输出