服务器入口的解构：接受（接口）→ 解析 → 分发 → 调用

主线 01 把 CLI 入口解构成「接受 → 解析 → 分发 → 调用」四段骨架。服务器入口同样可以被解构——除了「接受」这一步不同（CLI 接收参数，服务器通过网络接口接收消息），后面的解析层、分发层、调用层三层结构与 CLI 完全一样。这一篇是「服务器入口的解构」独立线：说明服务器入口为什么也是四段骨架、每一段在服务器里的具体形态是什么、以及它和 CLI 入口的唯一差异。

一、入口骨架是同一个：接受 → 解析 → 分发 → 调用

无论 CLI 还是服务器，「入口」做的事都是同一件事：把外部输入变成对业务的调用。

1 2	入口骨架（主线 01 解构出来的四段）：接受 → 解析 → 分发 → 调用 → 业务

CLI 和服务器都是这个骨架的具体实例，只是每段的「输入长什么样」不同：

1 2	CLI 入口：接受（参数 argc/argv）→ 解析 → 分发 → 调用 → 业务服务器入口：接受（网络接口消息） → 解析 → 分发 → 调用 → 业务

骨架相同，接受不同。

二、服务器入口的四个阶段

以一次 HTTP 请求为例：

POST /login
  → 网络接口收到字节（接受）
  → Parser：字节 → 请求（解析层）
  → Router/Dispatcher：请求 → 对应 Handler（分发层）
  → Handler：调用业务 Service（调用层）
  → Service 返回结果 → Handler 转成响应 → 网络接口发回

服务器入口：
  接受    网络接口（socket/HTTP 服务器）收到消息字节
  解析层  Parser：字节/消息 → 命令（请求）
  分发层  Router/Dispatcher：命令 → 对应 Handler
  调用层  Handler：调用业务功能，返回结果

服务器入口就是由这四个阶段组成的——它不是没解构，而是每一段都长成了服务器自己的样子。

三、每一段在服务器里的具体形态

接受：网络接口（vs CLI 的参数）

1
2
3

CLI：   接受 = main(argc, argv)，参数从命令行进来
服务器：接受 = 网络接口（socket 收字节、HTTP 服务器收请求），
        消息从网络进来

这一段的差异是输入来源不同：参数是一次性的、进程序就结束；网络消息是持续的、随时会来。但「接受」在骨架里只占一段——它决定后面解析什么，不改变骨架本身。

解析层：Parser

1
2
3

职责：把收到的字节/消息转换成程序能理解的命令（Request）
输入：网络接口收到的原始数据
输出：结构化的请求（命令 + 参数）

CLI 的解析层把 argv 解析成命令；服务器的解析层把消息体解析成请求。两者做的是同一件事——把输入变成命令。

分发层：Router / Dispatcher

1
2
3

职责：根据命令找到处理它的 Handler
输入：解析出的请求
输出：对应的 Handler（或 404「未知命令」）

CLI 的分发层根据 cmd 找到 handler；服务器的分发层根据 URL/命令码找到 controller/handler。都是命令 → Handler 的映射。

调用层：Handler

1
2
3

职责：调用业务功能，把结果转成响应
输入：请求
输出：业务结果 / 响应消息

Handler 是入口系统调用业务系统的最后一环——它知道「这个命令对应业务里的哪个功能」，但它自己不做业务。

四、服务器入口也是三层结构

和 CLI 入口一样，服务器入口解构后的主体是三层：

解析层（输入 → 命令）
  ↓
分发层（命令 → Handler）
  ↓
调用层（Handler → 业务）

「接受」不是一层，是进入骨架的一步——CLI 用参数进入，服务器用网络接口进入。进入之后，解析、分发、调用三层完全一样。

入口骨架 = 接受 → 解析 → 分发 → 调用

客户端入口（CLI，主线 01 已解构）：接受 = 接收参数
服务器入口（本线，已解构）：        接受 = 网络接口接收消息
两者后面的结构相同：
  解析层 + 分发层 + 调用层

五、为什么需要单独这条线

服务器入口的解构散落在两处，各自不完整：

1
2
3

主线 01：把 CLI 入口解构了（接受→解析→分发→调用），但没提服务器
服务器与三系统边界线：讲了服务器内部的 Parser/Dispatcher/Handler，
        但没有点明「这就是入口骨架在服务器上的解构」

本篇把两者对齐：服务器的 Parser/Dispatcher/Handler 不是服务器特有的新概念，就是入口骨架的解析层/分发层/调用层在服务器场景的具体形态。 这样服务器入口不再是一个「没解构的整体」，而是和 CLI 入口一样被解构成四段骨架。

六、和其他线的关系

服务器入口的解构 ←→ 从指令到系统/01（CLI 入口骨架）
  01 解构了 CLI 入口（接受→解析→分发→调用），本线证明服务器入口是同一个骨架

服务器入口的解构 ←→ 服务器与三系统边界（04-系统角色/06）
  边界线讲服务器怎么和业务/网络接边界
  本线讲服务器入口内部怎么解构——边界线的 Parser/Dispatcher/Handler 正是本线的三层

服务器入口的解构 ←→ 从指令到系统/03（三系统协作）
  03 的入口系统就是「入口骨架」的实例：解析层 + 分发层 + 调用层

服务器入口的解构 ←→ 系统角色/入口系统
  入口系统的职责是「接受外部输入 → 解析 → 分发 → 调用」，
  服务器是入口系统的长期运行形态

服务器入口的解构 ←→ GUI-MVVM（04-系统角色/08，本主题内）
  GUI 入口把四段骨架进一步拆到 View/ViewModel/用户流程
  服务器入口同样按四段骨架解构——都是同一个入口骨架在不同交互形态上的展开

收束

入口骨架（主线 01）：接受 → 解析 → 分发 → 调用

CLI 入口：   接受 = 参数（argc/argv）
服务器入口： 接受 = 网络接口（socket/HTTP 收消息）

唯一的差异在「接受」：
  参数是一次性的，网络消息是持续的
  但接受之后，解析层、分发层、调用层三层结构完全一样

服务器入口的具体形态：
  解析层 Parser（消息 → 请求）
  分发层 Router/Dispatcher（请求 → Handler）
  调用层 Handler（Handler → 业务）

所以服务器入口不是「没解构的整体」，
而是入口骨架在服务器场景的解构——与 CLI 入口互为镜像。