HespethornのBlog

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）作为物联网（IoT）领域广泛应用的通信协议，其核心优势之一在于通过可配置的服务质量（Quality of Service，QoS）等级，实现消息传输可靠性与资源开销的动态平衡。对于物联网开发者而言，深入理解QoS的设计逻辑、交互机制（握手流程）及应用场景适配原则，是保障设备间通信稳定性、优化系统资源配置效率的关键前提。 一、MQTT QoS 核心定位：为何需要多等级服务质量？物联网场景中的终端设备呈现显著的异构性特征，既包含联网稳定性高、计算能力充足的工业网关设备，也涵盖电池供电、带宽资源受限的低功耗传感器（如LoRa传感器、NB-IoT设备等）；同时，传输环境的差异性突出，既涉及丢包率低的稳定局域网，也包括丢包率较高的无线广域网（如蜂窝网络边缘区域）。若采用单一的消息传输策略，极易出现两类问题：其一，为追求传输可靠性而引入复杂的确认机制，导致资源受限设备的不必要开销；其二，忽视传输可靠性保障，造成核心业务指令（如工业控制指令）丢失，影响系统正常运行。 MQTT协议设计QoS机制的...

在 C++11 之前，实现异步任务往往需要手动管理线程（std::thread）、同步原语（std::mutex、std::condition_variable），不仅代码繁琐，还容易出现线程泄漏、死锁等问题。C++11 引入的 std::async 彻底改变了这一现状——它是高层异步编程接口，能轻松创建异步任务并获取结果，无需手动管理线程生命周期，是异步编程的“瑞士军刀”。 本文将从 核心概念、使用场景、参数详解、返回值处理、常见陷阱 五个维度，带你彻底掌握 std::async。 一、核心概念：std::async 是什么？std::async 是 <future> 头文件中的函数模板，作用是 启动一个异步任务，并返回一个 std::future 对象。核心特点： 异步执行：任务可能在新线程中执行，也可能在调用 get()/wait() 时同步执行（取决于启动策略）； 结果获取：通过返回的 std::future 对象获取任务执行结果（或异常）； 线程管理：由标准库管理线程（如线程池复用），无需手动 join() 或 detach()，避免线程泄漏。 ...

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）作为物联网（IoT）领域广泛应用的轻量级机器对机器（M2M）通信协议，凭借低带宽占用、低功耗消耗及低传输延迟等核心优势，成为设备间数据交互的主流技术方案。在MQTT协议的核心特性体系中，**保留消息（Retain Message）与遗嘱消息（Last Will and Testament，简称Last Will）**是保障消息传输可靠性及设备运行状态感知能力的关键机制。本文将系统剖析二者的技术原理、应用场景、潜在风险，并结合物联网实际部署需求提出针对性的最佳实践策略。 一、保留消息（Retain Message）：新订阅节点的主题状态快照机制MQTT保留消息指消息代理（Broker）对发布者发送的携带保留标识（Retain Flag = 1）的消息进行持久化存储。当新订阅者订阅该消息对应的主题时，Broker会主动将存储的该主题最新保留消息推送至新订阅者。本质而言，保留消息机制为主题提供了“最新状态快照”功能，使新订阅者无需等待发布者后续的消息推送，即可快速获取主题对应的...

在物联网（IoT）及移动终端应用领域，协议的轻量化与传输高效性是核心选型准则。此类场景中，大量终端设备（如传感器节点）存在算力与能源受限问题，且网络环境常面临带宽瓶颈与稳定性不足等挑战。消息队列遥测传输（MQTT）协议自1999年问世以来，凭借其极致的轻量化设计与高效的传输性能，已成为IoT领域主流通信协议之一，同时在移动终端推送、车联网等场景中得到广泛应用。 一、MQTT协议轻量高效的核心实现机制：基于设计细节的优化MQTT协议的轻量性与高效性并非依赖单一技术创新，而是通过报文格式、连接管理、通信架构等多维度的“减法设计”与精准优化实现的，其设计核心始终围绕“降低资源占用、提升传输效率”两大目标展开。 1. 极简报文结构设计：降低带宽占用，适配小数据传输报文是协议通信的核心载体，MQTT协议采用极简报文结构设计，核心目标为最小化数据传输量，这一设计对带宽资源受限的IoT场景（如蜂窝网络、LoRa网关通信场景）具有重要适配价值。 MQTT报文由固定头、可变头与有效载荷三部分构成，其中固定头为必选模块，最小长度仅2字节——这意味着即使是空消息传输，其开销也仅为2字节，远低于HTTP...

在物联网（IoT）、移动互联网等现代信息通信领域，通信协议的选型直接决定系统的性能表现、运行稳定性及运维成本。消息队列遥测传输（MQTT，Message Queuing Telemetry Transport）协议作为面向低带宽、低功耗终端设备设计的轻量级通信协议，与传统的超文本传输协议（HTTP，HyperText Transfer Protocol）在技术架构、传输特性等方面存在显著差异。 一、核心维度对比概览为清晰呈现两种协议的核心差异，首先通过表格对各关键维度进行归纳对比，为后续的深度分析构建基础框架。 对比维度 MQTT HTTP 架构模式 发布/订阅（Pub/Sub）架构，依赖中间代理节点（Broker）实现消息转发 客户端/服务器（C/S）架构，无中间转发节点，采用点对点直接通信模式 连接方式 基于TCP协议的长连接机制，连接建立后持续保持，支持心跳保活（Keep-Alive）机制保障连接稳定性 默认采用TCP短连接（HTTP/1.0），请求-响应完成后连接即释放；HTTP/1.1支持长连接...

在物联网（IoT）场景中，设备与设备、设备与云端的通信需要面对三大核心挑战：带宽有限（如传感器、智能硬件多采用蜂窝网络/蓝牙）、设备资源受限（低功耗芯片算力/内存有限）、网络不稳定（移动场景下频繁断连）。而 MQTT 协议正是为解决这些痛点而生的轻量级消息传输协议——它像物联网世界的“微信”，让海量设备能高效、可靠地传递信息。 本文将从“是什么-为什么用-核心原理-实战场景”四个维度，用工程师易懂的语言拆解 MQTT，既讲清底层逻辑，也给出实际应用参考。 一、MQTT 核心定义：物联网的“轻量级通信协议”1. 协议本质MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是 1999 年诞生的基于发布/订阅（Pub/Sub）模式的应用层协议，专为低带宽、高延迟、不可靠网络设计。 核心定位：“物联网场景的 TCP/IP 补充”——基于 TCP 协议实现可靠传输，同时通过极简的协议头、灵活的 QoS 机制，降低设备通信成本。 2. 关键特性（为什么物联网首选 MQTT？） 特性 具体说...

一、核心需求与版本规则复盘在动手前先明确核心目标，避免版本管理混乱： 版本格式：主版本.MINOR.补丁版本（语义化规范，如 2.3.15） 规则 1：主版本 / 小版本（MINOR）手动更新时，补丁版本重置为当前 Git 提交数 规则 2：无主 / 小版本变更时，补丁版本自动跟随 Git 提交数递增 规则 3：版本号需嵌入代码（如 version.h）、构建产物（如二进制文件名）、CI/CD 流程 优势：无需手动维护补丁版本，Git 提交记录即版本追溯依据，避免重复或遗漏。 二、CMake 实现方案（零外部依赖）核心思路：用 CMake 内置命令调用 Git 获取提交数，结合手动配置的主 / 小版本，自动生成完整版本号，并同步到代码和构建流程。 1. 完整 CMake 脚本（version.cmake）创建独立的 version.cmake 文件（便于复用），放入工程根目录： 12345678910111213141516171819202122232425262728293031323334353637383940414...

1. 文档目的用于 Linux 主机使用 systemd 管理服务的方式，包括： 服务文件规范 统一的日志与目录要求 启停、上线、变更流程 服务异常排查方法 常见问题解决 适用于：后端服务、守护进程、数据处理任务等所有 systemd 托管的服务。 2. 服务文件基本规范2.1 服务文件位置与命名 项目 规范 存放路径 /etc/systemd/system/ 文件后缀 .service 命名方式 project-name.service（全部小写，使用短横线连接） 示例： 12myserver-api.service job-dispatcher.service 禁止 放在 /usr/lib/systemd/system/（避免被系统升级覆盖） 使用大写或空格命名 2.2 文件权限与属主 项目 要求 权限 644 所有者 root:root 命令： 12sudo chown root:root /etc/systemd/system/myserver.servicesudo chmod 644 /etc/systemd/sy...

在 Linux 系统运维与开发中，服务管理是核心基础能力之一。从早期的 SysV init 到如今主流的 systemd，服务管理机制经历了颠覆性的变革。作为工程师，理解二者的设计差异、systemd 的核心架构以及其与内核的交互逻辑，不仅能提升日常运维效率，更能在服务调优、故障排查中直击本质。 一、从 SysV init 到 systemd：服务管理的演进逻辑在 systemd 普及之前，Linux 系统普遍采用 SysV init 作为初始化系统（PID 1），其核心是基于脚本的串行启动机制。每个服务对应 /etc/init.d/ 目录下的一个 Shell 脚本，启动顺序由 /etc/rc*.d/ 中的符号链接优先级（如 S01xxx、S99xxx）决定。这种设计简单直观，但存在三个致命缺陷： 串行启动效率低：服务按顺序逐一启动，即使服务间无依赖关系，也需等待前一个服务启动完成，导致系统启动耗时过长； 依赖管理简陋：依赖关系需通过脚本内的逻辑或启动优先级手动维护，易出现依赖缺失或顺序错乱问题； 监控与控制能力弱：对服务的运行状态监控、异常重启、资源限制等支持不足，需依赖第三...

在开发脚本引擎或配置解析工具时，我们经常需要处理多种类型的语句（赋值、条件、循环等）。本文将通过一个实用的语句解析器案例，展示如何用注册式工厂模式构建易于扩展的解析系统。 一、需求分析与设计思路我们需要开发一个支持以下语句类型的解析器： 赋值语句（如x = 100） 条件语句（如if x > 5） 循环语句（如for i in 0..10） 核心挑战是：当需要支持新语句类型时，无需修改现有解析逻辑，只需添加新的解析器实现。这正是工厂模式的用武之地。 整体设计方案： 定义抽象解析器接口（基类） 为每种语句实现具体解析器（派生类） 用注册式工厂管理解析器的创建 通过语句特征自动匹配对应的解析器 二、核心代码实现1. 抽象解析器接口首先定义所有解析器的公共接口： 12345678910111213#include <string>// 语句解析器基类class StatementParser {public: virtual ~StatementParser() = default; // 解析语句（提取关键信息）...

在软件开发中，工厂模式是解耦对象创建与使用的经典方案。但传统工厂模式在面对频繁新增产品时，总会陷入修改工厂类的尴尬。本文将带你探索如何用 C++ 模板实现自动注册的工厂模式，彻底解决这一痛点。 一、传统工厂的 "if-else 地狱"假设我们要开发一个支持多种日志输出的组件（控制台日志、文件日志、网络日志），传统工厂实现可能是这样的： 123456789101112131415161718class Logger {public: virtual void log(const std::string& msg) = 0; virtual ~Logger() = default;};class ConsoleLogger : public Logger { /* 实现 */ };class FileLogger : public Logger { /* 实现 */ };class LoggerFactory {public: static std::unique_pt...

一、Gerrit 是什么？为什么需要它？Gerrit 是一款基于 Git 的开源代码审查工具，核心价值在于强制代码评审流程，通过多人协作把关代码质量，减少线上缺陷，同时保留完整的变更追溯记录。它特别适合中小型团队： 支持细粒度权限控制（谁能提交 / 评审 / 合并代码） 与 Git 原生兼容，无需改变现有开发习惯 网页端可视化评审界面，支持评论、打分、变更追踪 可集成 CI/CD 流程（如 Jenkins、GitHub Actions），实现自动化验证 对比直接提交 Git 仓库：Gerrit 通过「虚拟分支」机制拦截直接提交，确保所有代码变更都经过评审，尤其适合需要严格质量管控的 C/C++ 工程（如嵌入式、工具类项目）。 二、环境准备与安装配置（服务器端）1. 核心依赖 操作系统：Linux（推荐 Ubuntu 20.04+/CentOS 7+） 依赖软件：Java 8+（Gerrit 基于 Java 开发）、Git、数据库（默认 H2，生产环境推荐 MySQL/PostgreSQL） 2. 安...

一、基础认知：版本号规范与核心逻辑在开展实操之前，需明确两个核心基础内容：版本号的规范化格式标准与该方案的核心实现逻辑，为后续操作提供理论支撑。 1. 语义化版本规范（SemVer）建议采用「语义化版本规范（Semantic Versioning, SemVer）」，其格式定义为：主版本号.次版本号.补丁版本号（例如 v1.2.3），各组成部分的语义含义如下： 主版本号（Major）：当项目进行不兼容的API变更时递增，此时旧版本代码无法直接适配（例如 v2.0.0，代表项目功能架构发生重大调整）； 次版本号（Minor）：当项目新增向后兼容的功能时递增，不影响现有代码的正常运行（例如 v1.3.0，代表在原有基础上扩展功能）； 补丁版本号（Patch）：当项目进行向后兼容的问题修复时递增，仅修正缺陷不新增功能（例如 v1.2.4，代表针对现有版本的Bug修复）； 可选后缀：包括预发布版本标识（例如 v1.2.3-beta，用于标识测试阶段版本）与构建信息（例如 v1.2.3+20241201，用于记录版本编译时间）。 2. 整体实现逻辑该方案的核心逻辑可概括为：通过...

一、什么是 YAML？—— 不止于「另一种配置文件」YAML 全称 YAML Ain't Markup Language（YAML 不是标记语言），听着像绕口令，核心却是「反标记语言」的设计理念：用最简洁的语法描述数据结构，让人类一眼能看懂，机器也能轻松解析。 它诞生于 2001 年，初衷是替代 XML 的繁琐标签和 JSON 的大括号，如今已成为配置文件的「首选格式」—— 你在 Kubernetes、Docker Compose、Spring Boot、GitHub Actions 等场景中，随处可见它的身影。 核心定位：人类可读、机器可解析的数据序列化语言，专注于配置场景的简洁性和易用性。 二、为什么选择 YAML？—— 三大核心优势对比 XML、JSON，YAML 的优势一目了然： 特性 XML（繁琐） JSON（简洁但局限） YAML（平衡之选） 语法简洁度 需闭合标签（） 需大括号 / 引号，无注释 无多余符号，支持注释 可读性 低（标签冗余） 中（结构清晰但缺乏注释） 高（自然语言般的层级） 数据类型支持 需定义 schema...

步骤 1：说明编译与运行时工作目录的分离特性首先，我们必须明确一个基本原则：编译器的工作目录和程序运行时的工作目录是两个完全独立的概念。 1.1 编译时路径解析编译器（如GCC, Clang, MSVC）在处理源代码时，主要涉及两种路径： #include "my_header.h"：这种形式的包含指令，编译器会首先在包含该指令的源文件所在的目录下查找my_header.h。如果找不到，再在编译器指定的系统或用户包含路径（通过-I参数指定）中查找。 #include <iostream>：这种形式，编译器会直接在系统或用户指定的包含路径中查找，而不会在当前源文件目录中查找。 关键点：编译时的路径解析是为了定位源文件和头文件，以便将它们组合成一个翻译单元并生成目标文件（.o或.obj）。这个过程与程序最终运行时需要读取的数据文件（如配置、图片、资源）毫无关系。 1.2 运行时路径解析当你的程序被编译链接成可执行文件并启动时，操作系统会为其创建一个进程。这个进程拥有一个重要的属性：当前工作目录。 所有运行时的相对路径文件操作（如std::ifstr...

一、BM25 算法核心原理：从公式到 C++ 实现关注点BM25（Best Matching 25）是基于概率检索模型的改进算法，核心是在 TF-IDF 的基础上增加文档长度归一化和参数可调性，解决 “长文档过度匹配” 的问题。理解原理时，需重点关注与 C++ 实现强相关的设计点。 1.1 核心公式与参数意义BM25 的单术语 - 文档相关性评分公式如下： $score(q, d) = IDF(q) \times \frac{TF(q, d) \times (k_1 + 1)}{TF(q, d) + k_1 \times (1 - b + b \times \frac{len(d)}{avg_len})}$ 其中关键参数与 C++ 实现的关联的： $TF(q,d)$在文档$d$中的词频，需存储在倒排索引中，用float类型平衡精度与内存； $len(d)$文档$d$的长度（术语数），需在文档元数据中记录，用uint32_t节省内存； $avg_len$所有文档的平均长度，预处理阶段计算后全局缓存，避免重复计算； $k$词频饱和系数（通常取 1.2~2.0），控制...

一、C++11新特性概述记忆口诀：C++11新特性，语法库扩双提升；auto decltype智能指，nullptr范围循环使；右值引用move效，无序容器正则到；Lambda匿名函数好，代码简洁效率高。1. 语法改进 统一初始化方法 成员变量默认初始化 auto关键字：编译器自动推断类型 decltype：推导表达式类型 智能指针：std::shared_ptr、std::unique_ptr 空指针nullptr：替代NULL，类型明确 基于范围的for循环：简化容器遍历 右值引用和move语义：提高资源转移效率 2. 标准库扩充 无序容器（哈希表）：类似map但效率更高 正则表达式：模式匹配字符串 Lambda表达式：定义匿名函数 二、智能指针记忆口诀：智能指针分三类，shared_ptr共享随；引用计数来管理，线程安全要注意；unique_ptr独占权，禁止拷贝所有权；weak_ptr旁观态，lock检查免崩溃。1. shared_ptr（共享指针） 实现机制：基于引用计数，多指针共享同一资源 核心组件： 模板指针T* ptr：指向实际对象 引用计数器：共享引用次数，...

一、并发基础核心组件口诀：线程对象要管理，互斥锁来保安全，原子操作不可拆，条件变量通信忙1.1 std::thread - 线程管理 构造方式： 默认构造：创建空线程对象 初始化构造：thread t(func, args...)，传入函数和参数 移动构造：支持线程所有权转移，不支持拷贝 生命周期管理： join()：主线程等待子线程完成，阻塞当前线程 detach()：线程独立运行，与主线程分离 关键注意：线程对象销毁前必须调用join()或detach()，否则程序崩溃 常见陷阱：局部线程对象销毁时，若线程函数仍在运行会导致崩溃（解决：使用detach()或确保join()被调用） 1.2 std::mutex - 互斥锁 基本功能：保护共享资源，确保同一时间只有一个线程访问 核心方法：lock()（加锁）、unlock()（解锁）、try_lock()（尝试加锁，非阻塞） 使用建议：配合RAII包装器使用，避免忘记解锁导致死锁 1.3 std::lock_guard - RAII锁管理 核心特性：RAII风格的锁管理，构造时自动加锁，析构时自动解锁 优点：避免忘...

一、TCP Socket通信实现记忆口诀：服创绑监听，接收发关尽；客创连收发，关闭要记心。服务器端流程 创建socket：调用socket()创建流式套接字（TCP） 绑定地址：通过bind()将socket与IP地址和端口绑定 监听连接：使用listen()开启监听，设置最大连接队列 接受连接：调用accept()阻塞等待客户端连接，返回新socket 数据收发：使用send()和recv()进行数据传输 关闭socket：通信结束后关闭连接 客户端流程 创建socket：同服务器端 连接服务器：通过connect()向服务器发起连接请求 数据收发：同服务器端 关闭socket：通信结束后关闭连接 服务器端代码示例1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465#include <iostream>#include <cstring>#include <...

一、C++三大特性记忆口诀三大特性记分明，封装继承多态行；封装数据和操作，权限控制安全定；继承复用加扩展，子类父类心相印；多态接口行为异，编译运行两类型。 核心概念 封装：数据与操作打包，通过访问权限控制暴露（public/private/protected），提高安全性，隐藏实现细节 继承：子类拥有父类属性和行为，可在原有基础上扩展，实现代码复用 多态：同一种接口不同行为，分编译时多态（函数重载、运算符重载）和运行时多态（虚函数+继承） 代码示例123456789101112131415161718192021222324252627#include <iostream>using namespace std;// 封装class Animal {protected: string name;public: Animal(string n) : name(n) {} virtual void speak() { // 虚函数实现多态 cout << name ...

一、智能指针记忆口诀：智能指针三兄弟，unique独占share共享，weak观测防循环，RAII思想记心上智能指针是一种自动管理动态内存的工具类，用于防止内存泄漏。C++提供了三种常用的智能指针： unique_ptr（独占智能指针）： 独占对象所有权，同一时间只能有一个指针指向一个对象 禁止拷贝构造和拷贝赋值，支持移动语义 适合独占资源的场景 shared_ptr（共享智能指针）： 共享对象所有权，允许多个指针指向同一个对象 使用引用计数，当引用计数为0时释放资源 可以通过use_count()查看引用计数 weak_ptr（弱引用指针）： 不拥有资源，不增加引用计数 用于解决shared_ptr的循环引用问题 需要通过lock()方法提升为shared_ptr才能访问资源 RAII机制（资源获取即初始化）： 当创建智能指针对象时，它立即接管资源 当智能指针生命周期结束时，自动调用析构函数释放资源 无需手动调用delete，有效防止内存泄漏 代码示例1234567891011121314// unique_ptr示例std::unique_ptr&l...

一、JWT概念JWT（JSON Web Token）是一种用于在网络上安全传输信息的紧凑、自包含的方式。它由三部分组成：头部（Header）、载荷（Payload）和签名（Signature），通过点分隔的字符串形式呈现。在身份验证和信息交换场景中应用广泛，因为它可以验证信息的完整性和真实性。 1.1 准备工作在开始之前，我们需要确保系统中安装了libjwt库，这是一个轻量级的 JWT 实现库。在 Ubuntu/Debian 系统上，可以使用以下命令安装： 1sudo apt-get install libjwt-dev 1.2 jwt.cc1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889#include <jwt.h>#include <stdio.h>#i...

一、STL容器总览口诀：三容器两适配，序列关联加无序1.1 容器分类 序列容器：vector(动态数组)、list(双向链表)、deque(双端队列)、array(固定数组)、forward_list(单向链表) 关联容器：set(有序唯一集合)、map(有序键值对)、multiset(有序可重复集合)、multimap(有序可重复键值对) 无序容器：unordered_set、unordered_map、unordered_multiset、unordered_multimap 容器适配器：stack(栈)、queue(队列)、priority_queue(优先队列) 1.2 底层结构与性能对比 vector/deque: 动态数组，支持随机访问 list/forward_list: 链表，高效插入删除 set/map: 红黑树，有序且查找/插入为O(logN) unordered_*: 哈希表，平均O(1)查找/插入，无序 二、序列容器详解口诀：vector动态连续，list插入灵活，deque双端高效，array固定性能...

一、变量类型及其存储特性【记忆口诀】三变量，作用域不同；生命周期各有别，存储位置要分清1.1 静态局部变量、全局变量、局部变量的特点与使用场景定义与特性： 静态局部变量：函数内定义，static修饰；生命周期为整个程序，仅初始化一次，存储在数据段 全局变量：函数外定义；生命周期为整个程序运行区间，程序中任何地方可访问，存储在数据段或BSS段 局部变量：函数内定义；作用域和生命周期仅限于函数体内，每次调用重新创建，存储在栈上 表格对比： 分类 局部变量 静态局部变量 全局变量 作用域 当前函数或者代码块内 当前函数内部（外部不能访问） 整个程序内 生命周期 每次进入函数创建，用完就没 程序一运行就存在，一直到程序结束 程序启动时创建，程序结束才销毁 初始化行为 （不赋值则值为随机值，取决于栈区残留数据） （仅初始化一次，基本类型默认值为0，存储在数据段） （基本类型默认初始化为0，存储在数据段或BSS段） 存储位置 栈区（stack），速度快但不持久 数据段或BSS段（非栈），可长期保存 数据段或BSS段，生命周期长 适合场景 做临时运算，比如循环里...

要将双栈 TCP 回声服务器从线程池模式改造为Reactor 模式，核心是基于I/O 多路复用（epoll） 实现 “事件驱动” 的高效 I/O 处理 —— 通过单线程（或主线程）监听多个 Socket 的 I/O 事件，事件触发时再分发到对应处理器，避免线程上下文切换开销，更适合高并发场景。 一、Reactor 模式核心原理与组件Reactor 模式（反应器模式）是一种事件驱动架构，核心思想是 “将 I/O 事件从业务逻辑中分离”，通过以下组件实现： 组件 作用 Reactor（反应器） 核心调度器：运行事件循环，通过 I/O 多路复用（epoll）等待事件，分发事件到处理器 EventDemultiplexer 事件多路分离器：封装 epoll，负责注册 / 删除事件、等待事件触发（本文用 epoll） EventHandler（处理器） 事件处理接口：定义handleRead/handleWrite/handleError等统一接口，子类实现具体逻辑（如 “新连接处理”“回声...