2026.04.28征图日记5（学习前端三件套）

上午准备继续学一下react，发现里面的语法很多都不熟悉，所以去了解了一下，react、vue都是框架，本质上还是跑在JavaScript、CSS和html上的
之后开始学习前端三件套（重点是JS）

昨天晚上和老汉说了我来江苏实习，不打算考研，我妈听说我要来江苏（其实已经到了，但没跟他们说），可能在担心我吧，早上在给我发消息，说应该呆在近一点的地方，儿行千里母担忧啊~

下午除了摸鱼就一直在学这个前端三件套
js变量、数据类型，js函数、事件、DOM

今日工作内容：

1、学习react框架
2、了解前端三件套：JavaScript、HTML、CSS基本文件结构
3、学习JavaScript语法

下阶段计划：
1、深入学习react及其衍生框架

如果我要看这个项目的并发支持，我应该看哪一部分代码？

为什么要用图这个数据结构，为什么不用其他的？

为什么使用图（Graph）数据结构

问题域的本质特征
首先，让我们看看数据处理流程的本质特征：

现实世界的数据处理流程：

场景1：简单的线性流程
图像 → 分割 → 分类 → 结果

场景2：分支流程
┌─ 分类A ─┐
图像 → 分割 ─┤ ├─ 合并 → 结果
└─ 分类B ─┘

场景3：复杂依赖流程
┌─ 分割 ───────────────┐
│ │
图像 ──────────┤ ▼
│ ┌─ 合并 ─┐
└─ 检测 ──────────┤ ├─ 结果
└─ 诊断 ─┘
关键观察：

一个节点可能有多个前驱（需要等待多个输入）
一个节点可能有多个后继（输出给多个下游）
节点之间存在复杂的依赖关系
这些关系不是线性的，也不是简单的树形结构

图结构的核心优势：表达多对多关系

这个模型是自研的吗，还是怎么实现的？

模型实现方式：

框架层：自研的 C++ 算法引擎（ms_engine），负责流程编排、插件管理、执行调度

插件层：每个模型类型对应一个 DLL 插件，封装具体的推理逻辑

算法层：使用开源深度学习框架（PyTorch、ONNX Runtime 等）实现模型训练和推理

模型文件：.fsnb 是自定义格式，内部包含 TorchScript 或 ONNX 模型

训练流程：通过 Python 脚本调用 PyTorch 进行训练，输出模型文件

类比理解：

ms_engine ≈ 操作系统：提供进程调度、资源管理
DLL 插件 ≈ 应用程序：实现具体功能
PyTorch ≈ 运行时库：提供深度学习计算能力
.fsnb 文件 ≈ 可执行文件：包含模型结构和权重

这种架构使得系统既能保持框架的稳定性和高效性，又能灵活集成各种先进的深度学习算法。

通信这块为什么用tcp，为什么不用其他的方法，tcp好在哪；

大文件传输 — 模型文件（.fsnb）和样本数据动辄几百 MB，TCP 的流式传输天然适合，不需要像 HTTP 那样处理分块编码或 multipart 解析
可靠送达 — 推理任务必须完整到达设备，丢一个字节模型就加载失败。TCP 有重传、排序、校验和，保证数据完整性
自定义二进制协议 — 代码里定义了自己的帧格式：COMMAND_LENGTH(8) + UUID(36) + 元数据 + 1MB 分块数据。TCP 是字节流协议，帧边界自己控制，比 HTTP 的文本协议更紧凑高效
长连接 + 心跳 — 设备管理需要持续在线检测，TCP 连接本身就是”活”的，心跳包（heartbeat command）直接复用同一个连接
双向通信 — 推理完成后设备主动回传结果（receive_result），TCP 全双工天然支持

对比其他方案

HTTP REST
无状态短连接，大文件传输需要 multipart 分块，心跳需要额外机制，协议开销大（文本头）
UDP
不保证送达，推理任务不能丢包，需要自己实现可靠传输（等于重新发明 TCP）
WebSocket
适合浏览器场景，但 dev_manager 是设备间通信，WebSocket 的 HTTP 握手和帧格式是多余开销
gRPC
需要 Protobuf 定义，依赖较重，对嵌入式/边缘推理设备可能不友好
消息队列（Redis/RabbitMQ）
多一跳中间件，增加延迟和运维复杂度；设备是直接连接的点对点场景，不需要队列的解耦能力

TCP 的核心优势总结

在这个场景下，TCP 的本质价值是：可靠的、持久的、字节流级别的点对点连接。推理设备和 dev_manager 是一对一的关系，数据量大、不能丢、需要双向、需要知道对方是否在线——这些需求刚好是 TCP 的设计目标。

简单说：场景简单（点对点），要求高（可靠+大文件），TCP 是最直接的解法，不需要引入更复杂的中间件。