技术流：业务流每个步骤的「怎么做」链

业务流回答「做什么」——用户要完成的任务、程序要提供的能力；技术流回答「怎么做」——每个业务步骤在程序里如何实现。这一条线：把「怎么做」从一句笼统的话，展开成一条完整的决策链，并追踪它在五个演化阶段里的形态。

一、定义：做什么 vs 怎么做

同一个业务步骤，有两个视角：

1 2	业务流（做什么）：解析参数 → 格式化 → 返回结果技术流（怎么做）：怎么解析（strcmp？正则？）→ 怎么格式化（snprintf？流？）→ 怎么返回

业务流是用户视角：任务是「保存文件」，用户不关心用 fopen 还是 open。
技术流是实现视角：同一个「保存文件」，实现方式有无数种。

分层之前，二者常常被当成一回事——「保存文件」就是写那几行代码。分层之后，二者彻底分开：业务层写「做什么」，基础设施层写「怎么做」。

所以技术流的本质是：

每个业务步骤背后，都有一条「怎么做」的决策链。

二、技术流的展开：五个环节

「怎么做」不是一步到位的，它层层深入：

业务步骤（做什么）
  ↓ ① 功能流程：程序内部怎么组织步骤（先做什么、后做什么、什么条件下做什么）
  ↓ ② 算法：    步骤里的计算怎么算（怎么排序、怎么转换、怎么匹配）
  ↓ ③ 数据结构：数据怎么存（数组？链表？哈希表？）
  ↓ ④ 库/接口： 用什么现成的（自己写？还是调用库的接口？）
  ↓ ⑤ 技术方案：用什么技术（文件 vs 数据库？TCP vs UDP？）

以「保存进度」为例：

业务步骤：保存进度
  ↓ ① 功能流程：检查参数 → 序列化进度 → 写入存储 → 返回结果
  ↓ ② 算法：    序列化算法（进度数据 → 字节流）
  ↓ ③ 数据结构：进度数据怎么组织（结构体？键值对？）
  ↓ ④ 库/接口： 自己写文件操作，还是用库的文件接口（原子化封装）？
  ↓ ⑤ 技术方案：存本地文件？存数据库？同步写还是异步写？

五个环节不是五个并列的选项，而是同一条链上的递进：先组织步骤（①），再确定每步怎么算（②）、怎么存（③），然后决定用什么现成的（④），最后落到选什么技术（⑤）。

三、技术流的五阶段演化

单函数：技术流 = 代码本身

int main() {
    int a = atoi(argv[1]);       // 怎么做：直接写
    printf("%d\n", a * 2);
}

「怎么做」没有选择——就是那几行代码。技术流与代码重合，尚未独立。

单文件：技术流 = 函数的实现

1
2
3

int parse_arg(const char* s) {   // 业务：解析参数
    return atoi(s);              // 技术：用 atoi 转数字
}

怎么做开始有选择：用标准库 atoi 还是手写解析。技术流 = 函数内部怎么实现，但还散在代码里。

多文件：技术流 = 模块内的实现

怎么做有了位置：这个功能放哪个模块？用哪个模块的接口？

1 2	技术流（多文件）：这个功能放哪个模块 → 用模块里的哪个函数 → 那个函数内部怎么实现

技术流开始与「模块划分」「接口」交织——怎么做 = 在正确的模块里调用正确的接口。

多层：技术流第一次独立（质变点）

分层后，业务流和技术流第一次成为两条分开的链：

1 2	业务流（业务层）：解析参数 → 格式化 → 返回技术流（基础设施层）：调用库的文件接口（原子化封装）→ 调用操作系统 API

这是技术流独立的质变点：业务层不再关心怎么做，只关心「调用 file_api 保存」；怎么保存（用哪个库、哪个系统调用）是基础设施层的事。修改技术实现（换库、换系统调用），业务层不用动。

注意此时的技术流有一个特征：基础设施层里没有自己写的系统——它装的是其他库的接口或框架，接口直接接口化，框架也被转成接口（原子化封装）。技术流的这一环，本质是「把别人的能力接进来」。

多系统：技术流 = 选型

怎么做从「用什么函数」升级为「用什么系统」：

1
2
3

技术流（多系统）：
  收发消息 → 自建 socket 循环？还是用现成的网络系统？
  保存数据 → 自建文件系统？还是用现成的存储系统？

技术流的第五环（技术方案）在此放大为系统选型。选型产生两个后果：

引入依赖：选了网络系统，业务系统就依赖它（依赖关系线）。
决定封装形态：选来的系统接口化（上层调用接口）还是框架化（入口启动），决定了它怎么被使用（封装与调用线）。

四、技术流与相关线的关系

线	回答	与技术流的关系
业务分析 01~03（做什么链）	业务流程→功能点→功能流程+算法	技术流的上游：先有「做什么」，才谈「怎么做」；其产物（功能流程、算法）正是技术流的前两环
算法线	怎么算	技术流的第②环
数据结构线	怎么存	技术流的第③环
接口线	用什么形态暴露	技术流的第④环：库/接口选择之后，接口以什么形态存在（函数导出 / 类封装）
依赖关系	谁依赖谁	技术流的第⑤环的后果：选型引入依赖
封装与调用（网络系统）	系统怎么被使用	技术流选型后的落地：接口化还是框架化

关键区分：

1
2

业务分析线 = 产出「做什么」的完整链（流程→功能点→功能流程+算法）
技术流     = 接住业务分析线的产物，续上「怎么做」的完整链（流程→算法→存→库→方案）

业务分析线停在「功能流程 + 算法」；技术流从这里继续，补上数据结构、库/接口选择、技术方案三个环节，一直走到「用什么技术」——两条线正好首尾相接。

五、技术流的产物

每个业务步骤的技术流，最终沉淀为：

① 功能流程图    程序内部执行步骤（与业务分析03的功能流程一致）
② 算法设计      每步怎么算（与算法线一致）
③ 数据结构设计  数据怎么存（与数据结构线一致）
④ 库/接口清单   用什么现成的、封装成什么形态（与接口线一致）
⑤ 技术方案      用什么技术/系统（选型，引入依赖）

技术流不是一条运行时才会出现的流，而是一条设计期就定下来的决策链——它在写代码之前就要走完；运行时的执行流、功能流，只是这条决策链落地后的影子。

收束：技术流是什么

业务流：做什么 —— 用户的视角
技术流：怎么做 —— 实现的视角，展开为五环：

  功能流程 → 算法 → 数据结构 → 库/接口 → 技术方案

五阶段演化：
  单函数  单文件  多文件  多层           多系统
  代码本身 → 函数实现 → 模块实现 → 第一次独立 → 系统选型

技术流与业务流互为镜像：业务流是「做什么」的主线，技术流是「怎么做」的主线。分层让技术流第一次独立（业务层 vs 基础设施层），多系统让技术流放大为选型——每一次质变，都是「怎么做」被从「做什么」里拆出来的过程，本质是拆解与组织原则在实现维度上的投影。