在云服务无处不在的今天，HexoPress 选择了一条不同的路——本地优先。你的数据始终在你的电脑上，不经过任何第三方服务器。这不是技术上的妥协，而是一个深思熟虑的设计决策。
为什么是本地优先
Hexo 本身就是一个本地工具。它的博客数据——Markdown 源文件、配置、主题——全部存储在本地文件系统中。HexoPress 作为 Hexo 的图形化伙伴，自然应该尊重这个前提。
把数据留在本地意味着：
完全的数据所有权。 你的文章、草稿、图片，全部在你自己的硬盘上。没有账号，没有订阅，没有「服务条款变更」的风险。你可以用 Git 管理版本，用任何工具备份，用任何编辑器打开。
离线完全可用。 不需要网络连接就能写作、编辑、管理博客。唯一需要网络的功能是 AI 写作助手（因为它需要调用外部 API），但这是可选的。
零配置启动。 指向一个 Hexo 博客目录，就能开始工作。不需要注册账号，不需要配置数据库，不需要启动后端服务。
Hexo 作为库，而非 CLI
实现本地优先的一个关键技术决策是：将 Hexo 作为 Node.js 库直接嵌入应用，而不是通过命令行调用。
很多类似的工具选择通过 shell 执行 hexo 命令来与 Hexo 交互。这种方式简单直接，但有明显的局限：每次操作都要启动一个新的 Node.js 进程，解析文本输出，处理各种边界情况。
HexoPress 选择了更深度的集成方式。Hexo 的实例直接运行在 Electron 的主进程中，应用可以访问 Hexo 的内存数据库、查询 API 和文件解析器。这带来了几个好处：
- 启动后数据立即可用，不需要反复加载
- 查询操作在内存中完成，响应速度极快
- 文件操作通过 Hexo 的解析器完成，格式兼容性有保障
- 可以利用 Hexo 的完整数据模型，实现丰富的统计和筛选功能
文件系统即数据库
HexoPress 没有自己的数据库。所有的数据都来自 Hexo 博客目录中的文件：
- 文章内容来自
source/_posts/和source/_drafts/中的 Markdown 文件 - 分类和标签信息来自每篇文章的 Front Matter
- 媒体资源来自
source/目录中的图片和文件 - 博客配置来自
_config.yml
这意味着你在 HexoPress 中做的任何修改，都直接反映在文件系统上。用其他编辑器打开同一个文件，看到的是同样的内容。没有同步问题，没有数据格式转换，没有锁定效应。
与现有工作流的兼容
本地优先的设计让 HexoPress 可以无缝融入你现有的工作流：
- 用 Git 管理博客？HexoPress 的修改就是普通的文件变更，直接 commit 即可
- 习惯用 VS Code 写长文？随时切换，HexoPress 会自动感知文件变化
- 想用 CI/CD 自动部署？HexoPress 不会干扰你的部署流程
HexoPress 不试图取代你的工具链，而是成为其中的一环。它专注于做好可视化管理这件事，把其他的选择权留给你。
隐私与安全
本地优先也意味着更好的隐私保护。你的博客内容不会被上传到任何服务器（除非你主动使用 AI 功能并配置了外部 API）。应用本身不收集任何使用数据，不需要网络权限就能运行核心功能。
对于写作者来说，这种确定性很重要——你知道你的草稿在哪里，你知道谁能看到它们。