02 「服务端消费优先」设计哲学

02 「服务端消费优先」设计哲学

本节摘要:上一节看到拓扑里服务端是「唯一中枢」,这一节讲贯穿整个 OpenWork 的核心设计哲学——「服务端消费优先(Server-consumption first)」。它的意思很简单:App(包括桌面渲染进程和所有客户端)只是服务端 API 的客户端,绝不发明平行行为,凡是服务端能做的都走服务端。这条哲学看似平淡,却是 OpenWork 避免行为漂移、让多客户端天然一致的根本。本节讲清它的含义、它带来的红利,以及违反了会怎样。

一、哲学的精确表述

「服务端消费优先」可以拆成两条规矩:

举例对比:

• ✅ 「列出工作区」→ 渲染进程调服务端的「列工作区」API,服务端返回
• ❌ 「列出工作区」→ 渲染进程自己读本地文件系统搞一套(平行行为)

后者就是「发明平行行为」——它在客户端和服务端各做了一套,迟早会不一致。

💡 一句话记住:服务端是单一事实来源(single source of truth),App 只消费它,不另起炉灶。

二、为什么要有这条哲学

这条哲学解决一个工程痛点:行为漂移(behavior drift)。考虑没有这条哲学的场景:

渲染进程自己实现「列工作区」
   │
   ▼ 服务端也实现「列工作区」(给别的客户端用)
   │
   ▼ 时间推移:有人改了服务端的实现,忘了改渲染进程
   │
   ▼ 结果:桌面显示的工作区列表 ≠ 实际工作区列表
​

这就是行为漂移——同一件事在客户端和服务端各一套,改了一边忘了另一边,行为就不一致了。规模越大,漂移越严重。

「服务端消费优先」从根上消灭这个问题:只实现一遍(在服务端),所有客户端都调它。改一处,所有客户端同步生效,不可能漂移。

三、这条哲学带来的红利

1. 多客户端天然一致

因为所有客户端都调同一套服务端 API,它们的行为天然一致——桌面看到的、CLI Agent 看到的、企业云看到的,都是同一份真相。你不用担心「桌面能做但 CLI 不能做」。

2. 维护成本最低

每件事只实现一遍(在服务端)。改一处,所有客户端受益。没有「改了 N 个客户端」的重复劳动。

3. 客户端可以很薄

客户端只负责「展示 + 调 API」,逻辑很薄。这让新增客户端(比如未来加个移动端)成本很低——只要它会调 API 就行。

薄客户端(展示+调API)
   │
   ▼
服务端(所有业务逻辑)
​

4. 服务端可独立演进

因为客户端依赖的是 API(契约),不是实现,服务端内部怎么重构都行,只要 API 不变,客户端无感。

四、违反了会怎样

讲个反例感受一下。假设有人为了「快」,在渲染进程里偷偷自己实现了一份「读文件」逻辑(不走服务端):

渲染进程:自己读文件(平行行为)
   │
   ▼ 服务端也有「读文件」API
   │
   ▼ 后果:
   ├─ 权限绕过:服务端的权限检查(第 4 章)被绕开了,客户端能读不该读的
   ├─ 行为漂移:服务端改了读逻辑,客户端读的还是旧的
   └─ 多客户端不一致:CLI 走服务端读到新逻辑,桌面读到旧逻辑
​

最严重的是权限绕过——OpenWork 的权限治理在服务端(第 4 章),客户端自己读文件等于绕过了治理。这正是为什么「服务端消费优先」不容妥协:它不只是工程整洁问题,更是安全问题。

⚠️ 一票否决:代码评审里看到客户端绕过服务端自己实现业务逻辑,基本要被打回——尤其是涉及权限/文件/引擎的操作。

五、这条哲学和「拓扑」的关系

把这条哲学和上一节的拓扑对照,你会发现拓扑的形状就是这条哲学的体现:

• 渲染进程「只认服务端」→ 因为它是服务端客户端
• 服务端「独立成进程」→ 为了被多客户端共用(单一事实来源)
• 引擎「被服务端代理」→ 引擎访问也走服务端(避免客户端绕过)

换句话说,拓扑是「服务端消费优先」的物理体现。理解了哲学,你就能解释拓扑为什么长这样;理解了拓扑,你就能把哲学落到具体设计上。

六、一个边界:这条哲学的例外

诚实地说,这条哲学不是绝对的。有些事必须在客户端做,服务端做不了:

• 界面渲染:只能在渲染进程做(服务端不会画界面)。
• 窗口管理:只能在主进程做(服务端不管窗口)。
• 桌面专属集成(托盘、通知、快捷键):只能在主进程做。

「服务端消费优先」针对的是业务逻辑,不是说一切都在服务端。判断标准是:「这件事是不是业务逻辑?」是 → 走服务端;不是(纯展示/系统交互)→ 客户端做。

本节要点回顾

1. 哲学两条规矩:App 是服务端客户端;不发明平行行为(服务端能做的都走服务端)。
2. 解决行为漂移:只实现一遍(服务端),所有客户端调它,不可能不一致。
3. 四样红利:多客户端天然一致、维护成本最低、客户端可很薄、服务端可独立演进。
4. 最严重违反是权限绕过:客户端自己干业务逻辑,绕过了服务端的权限治理。
5. 拓扑是哲学的物理体现:渲染只认服务端、服务端独立、引擎被代理——都是这条哲学的落地。
6. 边界:针对业务逻辑,不是绝对;纯展示/系统交互在客户端做。

拓扑和哲学都清楚了,最后一件事——把它们串成一次具体的控制流旅程。这是下一节的主题。