HexoPress 最初是从桌面端的本地优先思路出发设计的。即使后来增加了自托管 Web mode，这个原则依然成立。只不过今天更准确的说法已经不是“所有东西都必须放在一台笔记本上”，而是“你的博客仍然存放在你自己控制的文件和基础设施里”。
今天的“本地优先”具体是什么意思
对 HexoPress 来说，本地优先意味着：
- 博客的真相来源依旧是磁盘上的 Hexo 项目
- 应用不会引入一个私有数据库来接管你的内容
- 你依然可以继续使用 Git、编辑器和部署流程
在桌面版中，这通常意味着博客直接存在你的本机上。在 Web mode 中，这意味着博客部署在你自己的服务器上，而不是被托管到某个第三方 SaaS 里。
为什么这个原则仍然重要
数据所有权
文章、草稿、媒体文件、配置和主题，本质上都还是普通文件。你可以自由备份、用 Git 审阅、在任意编辑器中打开，不会被某个应用的数据格式锁住。
更低的运维负担
桌面版依然接近零配置：指向本地 Hexo 目录就能开始工作。Web mode 虽然多了一个服务端，但因为它直接面向博客文件工作，而不是依赖一套额外业务数据库，所以整体运维模型依然比较简单。
与现有工作流兼容
HexoPress 的设计目标不是取代你的工具链，而是加入你的工具链。你可以继续用 VS Code、Git、CI/CD 或手动部署。HexoPress 做出的修改，归根到底还是文件修改。
Hexo 作为库，而不是 CLI 包装器
这个理念背后的技术基础之一，是 HexoPress 直接把 Hexo 作为 Node.js 库接入，而不是反复 shell 调用 hexo 命令。
这样运行时就能直接访问：
- Hexo 的数据模型
- 文章、分类、标签的查询能力
- Front Matter 的解析和写回逻辑
而且这套思路在两种运行模式下都成立：无论 Electron 还是 Web mode，底层服务最终都是直接面对 Hexo 项目本身，而不是把它当作一个黑盒命令行工具。
文件系统仍然是真相来源
HexoPress 不会给内容再加一层自己的数据库。它读写的仍然是 Hexo 项目已经在使用的那些文件：
source/_posts/和source/_drafts/下的 Markdown 正文source/下的媒体和静态资源_config.yml中的博客配置
这也是它能持续兼容 Hexo 生态和其他工具的原因。
离线与远程访问
桌面版仍然保留了最完整的本地优先优势：
- 普通写作和管理不依赖网络
- 核心博客管理能力不依赖外部服务
- 文件就在本机可见
Web mode 是一种有意识的权衡。你用更强的远程访问能力，换掉了“绝对本地”，但并没有失去所有权，因为部署环境仍然由你自己掌控。
隐私含义
HexoPress 的核心能力并不要求把博客内容发送到第三方服务。最主要的例外是 AI 助手，而那也只会发生在你显式配置了外部模型端点之后。
所以更准确的承诺是：HexoPress 管理的是你自己拥有的内容、你自己控制的基础设施、你自己已经在使用的文件格式。