C++高并发服务器实战：从Reactor模式到仿muduo库实现

1. 项目概述

最近在社区里看到不少朋友对C++网络编程和高并发服务器开发感兴趣，尤其是提到要仿写muduo这样的经典库。作为一个在这个领域摸爬滚打了十多年的老码农，我觉得有必要分享一下我的实战经验。muduo库确实是学习C++网络编程的绝佳范本，它把Reactor模式、多线程、事件驱动这些核心概念封装得相当优雅。但说实话，直接看源码对新手来说可能有点吃力，特别是那些回调嵌套、智能指针管理、线程安全的设计，没有足够的实战经验很容易绕晕。

我这次要分享的“仿muduo库高并发服务器”项目，不是简单的代码搬运，而是基于我对muduo设计思想的理解，结合自己多年踩坑经验，重新实现的一个教学+实战版本。我会重点拆解几个关键模块：从最基础的Buffer缓冲区设计，到核心的EventLoop事件循环，再到完整的TcpServer封装，最后加上HTTP协议支持。每个模块我都会讲清楚“为什么这么设计”，而不仅仅是“代码怎么写”。比如，为什么Buffer要用vector 而不用string？为什么Connection要用shared_ptr管理？时间轮定时器怎么和智能指针配合实现连接超时管理？这些设计决策背后的考量，才是真正值钱的经验。

这个项目适合有一定C++基础（至少熟悉C++11智能指针、lambda、std::function）、了解Linux系统编程（socket、epoll）的朋友。无论你是想深入理解网络库原理，还是准备面试时被问到“如何设计一个高并发服务器”，这篇文章都能给你实实在在的参考。我会尽量用大白话把复杂的概念讲清楚，并提供可以直接编译运行的代码示例——毕竟，能跑起来的代码才是好代码。

2. 核心架构与设计思想拆解

2.1 Reactor模式：事件驱动的核心

高并发服务器的核心思想就一句话：用尽可能少的线程处理尽可能多的连接。传统的一个连接一个线程（one-thread-per-connection）模型，在连接数上去之后，线程上下文切换的开销就能把CPU拖垮。Reactor模式（反应堆模式）就是为了解决这个问题而生的。

你可以把Reactor想象成一个高效的“事件分发中心”。它有一个核心的“事件循环”（EventLoop），这个循环里只做三件事：1）问操作系统“哪些文件描述符（fd）有事件发生了？”（通过epoll_wait）；2）把有事件发生的fd分发给对应的处理器（Channel）；3）处理器执行具体的读写操作。整个过程是“非阻塞”的——不会因为某个连接的数据没准备好就让整个线程傻等。

muduo（以及我们的仿写版本）采用的是“One Loop Per Thread”的架构。简单说，就是每个线程有自己的EventLoop，这个EventLoop管理着一批连接。主线程（main reactor）只负责接受新连接（accept），然后把新连接“分配”给某个子线程的EventLoop（sub reactor）去处理后续的读写。这样做的好处是，连接的处理完全在单个线程内完成，避免了多线程操作同一个socket带来的锁竞争，性能自然就上去了。

这里有个关键点：连接从主线程“转移”到子线程时，怎么保证线程安全？我们的做法是，所有对连接的操作（比如send数据、close连接）都封装成“任务”（Functor），通过队列提交给该连接所属的EventLoop线程去执行。EventLoop在每轮循环处理完IO事件后，会顺带执行这些队列里的任务。这就是所谓的“runInLoop”机制。

2.2 模块化设计：各司其职，降低耦合

一个健壮的网络库不能把所有代码都塞在一个文件里。我们的仿muduo库采用了清晰的模块化设计，每个类职责单一，通过明确的接口进行通信。下面这张表概括了核心模块及其职责：

这种设计的好处是，每个模块都可以独立测试和理解。比如你想研究缓冲区设计，就只看Buffer类；想弄明白事件分发，就聚焦EventLoop和Channel。模块之间的依赖关系清晰，后期维护和扩展也方便。

2.3 智能指针与资源管理：防止内存泄漏的利器

C++里手动管理内存是痛苦的根源，尤其是在多线程、回调众多的网络编程中。我们的库大量使用了C++11的智能指针，特别是std::shared_ptr和std::weak_ptr，来自动管理对象的生命周期。

Connection对象的管理：每个TCP连接对应一个Connection对象。这个对象可能被多个地方引用：TcpServer的连接管理表、EventLoop的任务队列、定时器任务等。我们使用std::shared_ptr<Connection>（别名PtrConnection）来管理它。当最后一个持有该指针的地方释放它时，Connection对象及其内部的Socket、Channel等资源会自动析构。这从根本上避免了忘记close(fd)导致文件描述符泄漏的经典问题。

定时器与弱引用的妙用：时间轮定时器需要管理每个连接的定时任务。如果直接用shared_ptr保存任务，会出现循环引用（任务持有Connection的shared_ptr，Connection又间接引用任务）。我们的解决方案是：时间轮内部用std::unordered_map<uint64_t, std::weak_ptr<TimerTask>>来保存任务。weak_ptr不增加引用计数，只是观察者。当需要刷新定时任务（比如连接有新数据到达）时，通过weak_ptr::lock()尝试获取一个shared_ptr，如果对象还存在（引用计数>0），就生成一个新的定时任务放入时间轮；如果对象已析构，lock()返回空指针，说明连接已关闭，无需处理。这样既实现了自动超时释放，又避免了内存泄漏。

踩坑心得：早期版本我曾尝试用裸指针管理Connection，结果在压力测试下，偶尔会出现“段错误”。用Valgrind一查，发现是某个回调函数执行时，Connection对象已经被另一个线程释放了。改成shared_ptr后，问题迎刃而解。记住，在现代C++多线程编程中，智能指针是你的好朋友，但也要理解shared_ptr的代价（原子操作开销）和weak_ptr的使用场景。

3. 核心模块深度解析与实现要点

3.1 Buffer模块：数据收发的“中转站”

为什么需要Buffer？因为TCP是流式协议，没有消息边界。你调用一次recv，可能收到半条消息，也可能收到一条半消息。直接把recv的数据交给业务层处理，业务层还得自己拼包，太麻烦。Buffer就是在内核的socket缓冲区和应用层之间加一个“用户态缓冲区”，帮我们处理粘包/半包问题。

我们的Buffer设计采用了一个vector<char>作为底层存储，配合读位置（_reader_idx）和写位置（_writer_idx）两个游标。可读数据范围是[_reader_idx, _writer_idx)，空闲空间分前后两段：[0, _reader_idx)是已读数据腾出的空间（前沿空闲），[_writer_idx, vector.size())是未使用的空间（后沿空闲）。

写入数据时的空间管理策略：

1. 如果后沿空闲空间足够，直接在后沿写入。
2. 如果后沿空间不够，但前后沿总空间足够，就把可读数据[_reader_idx, _writer_idx)移动到vector头部（memmove），重置游标，然后写入。
3. 如果总空间都不够，就扩容vector。

这个策略避免了频繁的内存分配和拷贝，是网络库中常见的优化手段。muduo的Buffer也是类似思路。

// Buffer的核心方法：确保有足够空间写入len字节数据 void Buffer::EnsureWriteSpace(uint64_t len) { if (len <= TailIdelSize()) return; // 后沿空间足够，直接返回 // 后沿不够，但前后沿总空间够，就移动数据 if (len <= TailIdelSize() + HeadIdelSize()) { uint64_t ras = ReadAbleSize(); std::copy(ReaderPosition(), ReaderPosition() + ras, Begin()); _reader_idx = 0; _writer_idx = ras; } else { // 总空间不够，扩容 _buffer.resize(_writer_idx + len); } }

一个容易忽略的细节：std::copy的第三个参数是目的地的起始迭代器，它要求目的地是“可写入的”。如果你传一个void*，编译器会报错。需要先转换为char*：std::copy(src_begin, src_end, (char*)buf);。我当初就在这里被编译器错误信息搞晕了半天。

3.2 Channel与Poller：事件管理的“黄金搭档”

Channel是“文件描述符（fd）的事件管理器”。每个需要监听事件的fd（比如监听socket、客户端连接socket、定时器fd）都会有一个对应的Channel对象。Channel内部保存了：

• 该fd感兴趣的事件（_events，如EPOLLIN | EPOLLOUT）
• Poller返回的实际发生的事件（_revents）
• 各种事件对应的回调函数（_read_callback,_write_callback等）

Poller是epoll的封装。它维护一个epoll实例（_epfd）和一个unordered_map<int, Channel*>，方便通过fd快速找到对应的Channel。它的核心方法Poll()调用epoll_wait，获取就绪的fd列表，然后从map中找到对应的Channel，设置其_revents，并放入返回的活跃Channel列表。

Channel与Poller的协作流程：

1. 用户创建一个Channel，设置好fd和回调函数。
2. 调用Channel::EnableRead()，该方法会设置_events |= EPOLLIN，然后调用Channel::Update()。
3. Channel::Update()调用Poller::UpdateEvent(this)。
4. Poller检查这个Channel的fd是否已在监控中。如果没有，用EPOLL_CTL_ADD添加到epoll；如果已有，用EPOLL_CTL_MOD修改监听事件。
5. EventLoop调用Poller::Poll()，得到一批活跃的Channel。
6. 对每个活跃Channel，调用Channel::HandleEvent()，该方法根据_revents判断发生了什么事件（可读、可写、错误等），执行对应的回调。

这种设计将“事件注册”和“事件处理”解耦。Poller只关心fd和事件，Channel只关心这个fd的事件该怎么处理。

3.3 EventLoop：反应堆的“心脏”

EventLoop是每个IO线程的核心循环。它的Start()方法通常是一个while循环，不断执行以下步骤：

void EventLoop::Start() { while (!_quit) { // 1. 获取活跃事件 std::vector<Channel*> active_channels; _poller->Poll(&active_channels); // 2. 处理活跃事件 for (Channel* ch : active_channels) { ch->HandleEvent(); } // 3. 处理任务队列 std::vector<Functor> functors; { std::unique_lock<std::mutex> lock(_mutex); _pending_functors.swap(functors); } for (auto& f : functors) { f(); } } }

这里有两个关键点：

1. 任务队列（_pending_functors）：为什么需要它？因为所有对Connection的操作（如Send()、Shutdown()）都必须在Connection所属的EventLoop线程中执行，以保证线程安全。如果其他线程（比如业务线程）想操作Connection，不能直接调用，而是要把操作封装成函数对象（std::function），通过RunInLoop()方法放入任务队列。EventLoop在每轮循环中会执行这些任务。
2. 唤醒机制：如果当前没有IO事件，epoll_wait会一直阻塞，那么任务队列里的任务就得不到及时执行。为了解决这个问题，我们引入了eventfd。eventfd是一个专门用于事件通知的文件描述符。当向任务队列添加任务时，我们同时向eventfd写入一个8字节的数据。这个eventfd也在epoll的监控列表中，写入操作会触发它的可读事件，从而唤醒阻塞的epoll_wait，让EventLoop得以继续执行任务队列。

实操心得：eventfd的读写必须用read/write，并且每次读必须读8个字节（一个uint64_t），否则内核缓冲区会一直有数据，导致epoll_wait不停地返回，形成“忙等待”。我在测试时就遇到过CPU 100%的情况，一查发现是read只读了1个字节。

3.4 TimerWheel：高效管理海量定时任务

连接超时管理是高并发服务器必须考虑的问题。一个连接建立后，如果长时间不通信（比如30秒），服务器应该主动关闭它，释放资源。最简单的想法是为每个连接设置一个定时器（timer），但连接数上万时，定时器的管理和触发会成为性能瓶颈。

我们采用“时间轮+智能指针”的方案，这也是muduo和Nginx等高性能服务器常用的方法。

时间轮（Timing Wheel）：想象一个表盘，有60个刻度（秒针走一圈）。每个刻度对应一个桶（bucket），桶里放一堆定时任务。我们有一个指针（_tick）每秒走一格。当指针走到某个刻度，就执行该刻度桶里所有的任务。如果一个任务要在delay秒后执行，就把它放到(_tick + delay) % 60的桶里。

智能指针的魔法：每个定时任务是一个TimerTask对象，用shared_ptr管理。当连接有新数据到达时，我们调用TimerRefresh()，它会通过weak_ptr找到旧的TimerTask，然后生成一个新的shared_ptr指向同一个对象（引用计数+1），并放入新的时间刻度桶。当旧的定时时刻到来，桶被清空，旧的shared_ptr析构，但引用计数只是从2减到1，对象不会真正销毁。直到新的定时时刻到来，最后一个shared_ptr析构，TimerTask的析构函数才会执行，关闭连接。

这种设计的好处是：

• 高效：添加、删除、刷新定时任务都是O(1)复杂度。
• 自动管理：利用shared_ptr的引用计数自动判断连接是否活跃，无需显式地取消旧定时器。
• 线程安全：所有定时器操作都通过RunInLoop放到EventLoop线程执行，避免了锁竞争。

// TimerWheel的关键方法：刷新定时任务 void TimerWheel::TimerRefreshInLoop(uint64_t id) { auto it = _timers.find(id); if (it == _timers.end()) return; // 关键：通过weak_ptr的lock()获取shared_ptr，增加引用计数 PtrTask pt = it->second.lock(); if (pt) { int pos = (_tick + pt->DelayTime()) % _capacity; _wheel[pos].push_back(pt); // 新的shared_ptr，引用计数+1 } // 旧的shared_ptr会在原时间刻度桶被清空时析构，引用计数-1 }

4. 从零搭建：TcpServer与HTTP服务器的完整实现

4.1 TcpServer：串联一切的“导演”

TcpServer是给库的使用者提供的最高层接口。用户只需要几行代码就能启动一个高性能服务器：

#include "tcpserver.hpp" int main() { TcpServer server(8888); server.SetThreadCount(4); // 设置4个IO线程 server.EnableInactiveRelease(30); // 30秒无通信自动关闭连接 // 设置回调：新连接建立 server.SetConnectedCallback([](const PtrConnection& conn){ std::cout << "New connection: " << conn->Id() << std::endl; }); // 设置回调：收到数据 server.SetMessageCallback([](const PtrConnection& conn, Buffer* buf){ std::string msg = buf->ReadAsStringAndPop(buf->ReadAbleSize()); conn->Send(msg.c_str(), msg.size()); // 回显 }); server.Start(); // 启动服务器 return 0; }

TcpServer内部做了哪些事？

1. 初始化：创建主EventLoop（_baseloop）、Acceptor、线程池。
2. 设置回调链：Acceptor的回调设置为TcpServer::NewConnection。当有新连接时，这个函数被调用。
3. 创建Connection：在NewConnection中，为新连接的fd创建Connection对象，设置各种回调（这些回调最终是用户通过SetMessageCallback等设置的），并选择一个EventLoop（从线程池轮询）来管理这个连接。
4. 启动连接：调用Connection::Establish()，将连接的Channel注册到其所属的EventLoop的Poller中，开始监听读事件。
5. 启动主循环：调用_baseloop.Start()，主线程进入事件循环，等待新连接。

线程池的工作分配：我们采用简单的轮询（Round-Robin）策略。LoopThreadPool维护一个EventLoop指针数组。每次新连接到来，调用NextLoop()返回下一个EventLoop。这样能把连接均匀分配到各个IO线程，避免某个线程负载过重。

4.2 Connection：连接生命周期的“管家”

Connection可能是最复杂的类，因为它要协调Buffer、Socket、Channel、定时器，还要处理各种回调。它的状态机设计值得仔细研究：

typedef enum { DISCONECTED, // 连接已关闭 CONNECTING, // 连接刚建立，待设置（半连接状态） CONNECTED, // 连接已建立，可通信 DISCONNECTING // 正在关闭（等待发送缓冲区数据清空） } ConnStatu;

连接建立的完整流程：

1. Acceptor接受新连接，创建Connection对象，状态为CONNECTING。
2. 调用Connection::Establish()，该方法通过RunInLoop在Connection所属的EventLoop线程中执行EstablishedInLoop()。
3. EstablishedInLoop()将状态改为CONNECTED，启动读事件监控，并调用用户设置的_connected_callback。
4. 从此，这个连接的所有IO事件都在其专属的EventLoop线程中处理。

数据发送的“异步”设计：用户调用conn->Send(data, len)时，数据并没有立即发送，而是被追加到_out_buffer（发送缓冲区），然后启动写事件监控。当内核发送缓冲区可写时，触发写事件，HandleWrite()被调用，才真正调用send系统调用发送数据。这样做有两个好处：1）避免在用户线程执行可能阻塞的send；2）可以批量发送数据，提高吞吐量。

优雅关闭连接：直接close(fd)是粗暴的，可能丢失还在发送缓冲区里的数据。我们的做法是：用户调用Shutdown()，状态改为DISCONNECTING。如果发送缓冲区还有数据，就继续监听写事件，等数据发完再真正关闭。如果发送缓冲区已空，立即关闭。

4.3 添加HTTP协议支持：从TCP到应用层

单纯的TcpServer只能处理字节流，要支持HTTP，我们需要在Connection和应用层之间加一个“协议解析层”。这就是HttpContext和HttpServer的作用。

HttpContext：解析状态机HTTP请求是文本协议，格式固定：请求行 + 头部 + 空行 + 正文。但TCP可能一次只送来半条请求。HttpContext就是一个状态机，记录当前解析到哪一步了：

typedef enum { RECV_HTTP_LINE, // 正在解析请求行（如 GET /index.html HTTP/1.1） RECV_HTTP_HEAD, // 正在解析头部（如 Content-Type: text/html） RECV_HTTP_BODY, // 正在接收正文 RECV_HTTP_OVER, // 请求接收完成 RECV_HTTP_ERROR // 解析出错 } HttpRecvStatu;

每次Connection的读回调收到数据，就把数据交给HttpContext解析。HttpContext根据当前状态，从Buffer中提取对应部分（比如用GetLineAndPop()读一行），解析完一部分就更新状态。直到状态变为RECV_HTTP_OVER，表示一个完整的HTTP请求已就绪，可以交给业务处理了。

HttpServer：路由与静态资源服务HttpServer内部维护几个“路由表”（_get_route,_post_route等），每个路由表是一组(正则表达式, 处理函数)对。用户可以通过类似server.Get("^/api/user/(\\d+)$", handler)的方式注册路由。

当收到一个完整HTTP请求后，HttpServer：

1. 判断是否为静态资源请求：检查请求方法（GET/HEAD）、路径合法性（防止../越权）、文件是否存在。如果是，读取文件内容，设置正确的MIME类型，返回。
2. 否则查找路由表：遍历对应方法的路由表，用正则表达式匹配请求路径。匹配成功，则调用注册的处理函数；匹配失败，返回404。
3. 组织响应：根据HttpResponse对象（状态码、头部、正文）生成符合HTTP格式的字符串，通过Connection发送。

一个简单的HTTP服务器示例：

#include "httpserver.hpp" int main() { HttpServer server(8888, "./wwwroot"); // 端口，静态资源根目录 server.SetThreadCount(4); // 注册路由：GET /hello server.Get("^/hello$", [](const HttpRequest& req, HttpResponse* rsp){ rsp->SetContent("<h1>Hello, World!</h1>", "text/html"); }); // 注册路由：GET /api/user/{id} server.Get("^/api/user/(\\d+)$", [](const HttpRequest& req, HttpResponse* rsp){ // req._matches[1] 包含正则捕获的id std::string user_id = req._matches[1]; rsp->SetContent("{\"id\": " + user_id + "}", "application/json"); }); server.Start(); return 0; }

5. 实战踩坑与性能调优经验

5.1 常见编译与运行时问题排查

问题1：Buffer读写越界导致段错误现象：服务器运行一段时间后随机崩溃，core dump显示在Buffer::Read或std::copy处。原因：ReadAbleSize()计算错误，或者MoveReadOffset()/MoveWriteOffset()移动的偏移量超过了实际可读/可写大小。排查：在Buffer的所有读写方法开头加断言：assert(len <= ReadAbleSize());和assert(len <= TailIdelSize());。用gdb调试时，崩溃点会直接指向断言失败的那一行。修复：仔细检查所有移动游标的代码。特别是ReadAndPop这类组合操作，确保先读后移，且移动量等于读取量。

问题2：Connection对象在回调中被提前释放现象：回调函数执行时访问Connection成员变量出现非法内存访问。原因：Connection对象用裸指针管理，在某个回调执行过程中，另一个线程（或定时器）调用了Release()，对象被delete。解决方案：所有需要跨线程（或跨回调）保存Connection引用的地方，都用std::shared_ptr<Connection>。在Connection类内部，如果需要传递自身的shared_ptr给回调，用shared_from_this()（注意：Connection必须继承std::enable_shared_from_this<Connection>）。

问题3：epoll的LT（水平触发）模式导致CPU 100%现象：服务器空闲时CPU占用率很高。原因：对于可读事件，LT模式下只要socket接收缓冲区有数据，就会一直触发。如果一次没有读完，下次epoll_wait会立即返回。我们的HandleRead每次读65536字节，但如果客户端发送的数据超过这个数，就需要多次触发才能读完。在此期间，epoll_wait会不断立即返回，形成“忙等待”。解决：改为边读边读，直到recv返回EAGAIN（表示本次无可读数据）：

void HandleRead() { char buf[65536]; while (true) { int ret = _socket.NonBlockRecv(buf, sizeof(buf)); if (ret > 0) { _in_buffer.WriteAndPush(buf, ret); } else if (ret == 0) { // 对端关闭连接 return ShutdownInLoop(); } else { if (errno == EAGAIN || errno == EINTR) { break; // 本次读完了 } else { return ShutdownInLoop(); // 其他错误 } } } if (_in_buffer.ReadAbleSize() > 0) { _message_callback(shared_from_this(), &_in_buffer); } }

5.2 性能优化要点

1. 避免内存碎片：使用对象池频繁创建销毁Connection对象（特别是短连接场景）会导致内存碎片。可以用对象池：预分配一批Connection对象，用完后不释放，放回池中复用。我们的代码中，Connection是用new创建的，可以改为从对象池获取。对象池实现可以用std::vector加空闲链表。

2. 减少系统调用：批量写数据我们的HandleWrite一次只调用一次send。如果发送缓冲区数据很多，可能需要多次触发写事件才能发完。可以尝试在HandleWrite里用循环，直到send返回EAGAIN：

void HandleWrite() { while (_out_buffer.ReadAbleSize() > 0) { ssize_t ret = _socket.NonBlockSend(_out_buffer.ReaderPosition(), _out_buffer.ReadAbleSize()); if (ret > 0) { _out_buffer.MoveReadOffset(ret); } else if (ret < 0) { if (errno == EAGAIN) break; // 内核缓冲区满了，下次再写 else return Release(); // 其他错误，关闭连接 } } if (_out_buffer.ReadAbleSize() == 0) { _channel.DisableWrite(); // 发完了，关闭写监听 } }

3. 时间轮大小的选择我们的时间轮默认60个刻度（秒），最大支持60秒的超时。如果业务需要更长的超时（比如300秒），可以增大_capacity，或者实现多级时间轮（秒轮、分轮、时轮）。但要注意，时间轮越大，每次RunTimerTask()清空桶的代价可能越大（虽然摊还复杂度还是O(1)）。

4. 日志输出的性能影响调试时我们喜欢用DBG_LOG打印日志，但频繁的fprintf或std::cout会影响性能，尤其是同步日志会阻塞IO线程。生产环境应该用异步日志库（如spdlog），或者至少把日志级别调高，减少输出。

5.3 扩展与定制建议

1. 支持SSL/TLS现代服务器几乎都需要HTTPS。可以在Connection和Socket之间加一个SSLWrapper层。建立连接后，先进行SSL握手，握手成功后再进行应用层数据读写。注意，SSL握手是阻塞的，需要特殊处理，或者用异步SSL库（如OpenSSL的异步模式）。

2. 添加WebSocket支持HTTP是请求-响应模式，WebSocket是全双工通信。可以在HttpServer的基础上，检测Upgrade: websocket头部，握手成功后，将Connection的协议从HTTP切换到WebSocket。WebSocket有自己的帧格式，需要实现对应的编解码器。

3. 配置化目前很多参数（如Buffer初始大小、时间轮刻度数、线程池大小）是硬编码的。可以设计一个Config类，从配置文件或命令行参数读取，使服务器行为更灵活。

4. 监控与统计添加连接数、QPS（每秒查询数）、流量统计。可以在TcpServer中维护计数器，定期输出或通过管理接口查询。这对于线上运维至关重要。

这个仿muduo的高并发服务器项目，从最底层的Buffer到最上层的HttpServer，完整实现大约需要2000行左右的C++代码（不包括测试）。虽然代码量不小，但每一行都有其设计考量。通过这个项目，你不仅能学到C++网络编程的实战技巧，更能理解一个工业级网络库是如何组织、如何解决并发问题、如何平衡性能与易用性的。最重要的是，有了这个基础，你再去看muduo、libevent这些成熟库的源码，会发现原来它们的设计思想是如此一脉相承。