企业官网建设流程全解析

写并发服务器这件事，真正难缠的往往不是业务逻辑，而是连接本身。我刚接触 muduo 这套 Reactor 内核网络库时，最困惑的就是“一个 accept 就能干完的事，为什么还要拆出 Acceptor、TcpConnection、TcpServer 这一大堆类”。后来把 Acceptor 和 TcpConnection 的源码读透，又动手跑通了一遍“建立连接—收发数据—优雅关闭”完整流程，才真正想明白这套设计的精妙之处。这篇是学习笔记系列第五篇，重点盯住三块：Acceptor 到底在监听时做什么、TcpConnection 是怎么从无到有建立起来的、一条连接做到优雅关闭而不是粗暴 close 需要走哪些步骤。

读之前先对齐一下基础：muduo 是典型的 one loop per thread + Reactor 模型，EventLoop 是事件循环，Channel 负责封装 fd 和事件回调，Poller 负责向操作系统注册并等待事件，Buffer 管读写缓冲。如果你已经把这几个东西弄清楚了，那 Acceptor 和 TcpConnection 就是连接从“监听”到“建立”再到“销毁”这条主干道上的两个关键节点。这篇笔记不需要你懂太多业务层的玩法，只要跟着代码走一遍连接的状态机，基本就能把 muduo 的连接管理整套逻辑串起来。

1. 分清 Acceptor 与 TcpConnection 的职责边界

1.1 一次完整连接的生命周期

在动手看代码之前，先把一张“连接生命周期图”装进脑子：服务端启动后监听 socket 创建好，进入等待状态；某个客户端发起三次握手，监听 socket 变得可读；Acceptor 把这个新连接 accept 出来，得到一个已连接的 fd；紧接着创建 TcpConnection 对象，把它挂到某个事件循环上，开始收发数据；之后某端要断开，发起关闭流程；最后 TcpConnection 对象被销毁，资源归还系统。

这条链路上有两个角色：Acceptor 只负责“接客”，它不关心连接之后要干什么，谁连上来了、后续怎么读怎么写，都不是它该管的事。而 TcpConnection 负责“伺候客”，一条连接从诞生到销毁的所有状态转移、数据读写、优雅关闭，都由它管理。一个服务器可以有无数条 TcpConnection，但正常情况下只有一个 Acceptor（除非你搞多端口监听）。

为什么非要拆开？你可以尝试把监听逻辑塞进 TcpServer 里，但很快就会碰到麻烦：监听 socket 的 fd 可以被放到某个事件循环上，连接对象的 channel 又需要被分配到不同线程的事件循环上。如果混在一起，回调上下文就乱了。muduo 的哲学是每个类只干一件事，并且把“事件分发”和“业务处理”严格隔开。看到这里先记住结论：Acceptor 是连接工厂，TcpConnection 是连接本体。

1.2 两个类各管哪一段

Acceptor 的职责范围非常窄，窄到甚至可以单独拿出来复用。它内部持有三样东西：一个 EventLoop 指针、一个 Socket 对象（封装监听 socket）、一个 Channel 对象（负责把监听 socket 的可读事件挂到事件循环上）。它的对外接口也很简单：调用 listen() 开始监听，然后通过 newConnectionCallback_ 把 accept 到的连接交出去。

TcpConnection 则复杂得多，它承载了完整的状态机：kDisconnected、kConnecting、kConnected、kDisconnecting 四个状态，外加一整套读写缓冲管理。它内部持有 EventLoop 指针、Socket、Channel、输入输出 Buffer，以及各类回调：连接建立回调、消息回调、写完成回调、关闭回调。

一个直观的理解方式：Acceptor 就像酒店的前台，客人按门铃（三次握手完成）后，前台开门让他进来，然后打电话通知客房部（事件循环）安排一位管家（TcpConnection）对接。前台不负责客房服务，管家也不负责门口接待。两者被一条 newConnectionCallback 回调串起来，而这个回调在 TcpServer 里被绑定成“创建 TcpConnection 并注册到 loop”。

2. Acceptor：监听 socket 如何持续产出一条条连接

2.1 构造与初始化：非阻塞 socket、地址复用、Channel 绑定

Acceptor 的构造函数非常有代表性，我见过不少初学者直接跳过这段，结果后面各种“莫名其妙”的问题都从这里埋下。核心代码如下（简化示意）：

Acceptor::Acceptor(EventLoop* loop, const InetAddress& listenAddr, bool reuseport) : loop_(loop), acceptSocket_(sockets::createNonblockingOrDie()), acceptChannel_(loop, acceptSocket_.fd()), listenning_(false), idleFd_(::open("/dev/null", O_RDONLY | O_CLOEXEC)) { acceptSocket_.setReuseAddr(true); acceptSocket_.setReusePort(reuseport); acceptSocket_.bindAddress(listenAddr); acceptChannel_.setReadCallback(std::bind(&Acceptor::handleRead, this)); }

先看 createNonblockingOrDie：这里创建的是非阻塞 socket，而且顺手设置了 close-on-exec。非阻塞的原因很直接——监听 socket 如果被设成阻塞，一旦 accept 时没有新连接，整个事件循环就卡死了，Reactor 模型直接崩塌。close-on-exec 则是为了防止 fork 子进程后意外继承 fd，造成资源泄漏和端口抢占问题。这两个细节，属于“不写就是事故，写了没人夸”的防御性做法。

setReuseAddr(true) 大家应该都很熟了，否则服务端重启时会报 “Address already in use”，因为 TCP 连接处于 TIME_WAIT 状态时端口还没释放。setReuseport 则是 Linux 3.9 以后提供的端口复用能力，允许多个进程绑定同一端口做负载均衡，muduo 把它设计成可配置项。

最后一步是把 Channel 绑定到读取回调。注意这里 Channel 并没有立刻 enableReading，也就是说此刻监听 socket 只处于“待命”状态，还不会触发任何事件。什么时候注册进 Poller？等到 listen() 被调用时才真正激活。

2.2 listen()：从闲置 socket 到开始工作的切换

void Acceptor::listen() { loop_->assertInLoopThread(); listenning_ = true; acceptSocket_.listen(); acceptChannel_.enableReading(); }

这段代码的逻辑不算复杂，但有一个容易被忽略的点：事件循环线程模型要求所有对 Channel 的注册、修改操作都必须发生在它所属的 loop 线程内。所以 listen() 里第一件事就是 assertInLoopThread()。如果你在业务线程里直接调用 Acceptor 的 listen，断言直接炸掉，这就是 muduo 帮你把线程安全问题暴露在早期的手段。

调用 listen() 后，监听 socket 进入 LISTEN 状态，Channel 也会被注册到 Poller。内核收到客户端 SYN 后，三次握手由内核完成，握手完成后监听 socket 会变得可读，Poller 检测到事件，回调 Acceptor::handleRead()。

这里值得多说一句：为什么不在构造函数里直接 listen？看起来好像没必要多暴露一个接口。但从设计角度，Acceptor 被 TcpServer 持有，TcpServer 可能在构造后还要做一堆初始化、解析配置、启动线程池之类的事情，它希望“开始监听”这个动作能由自己控制节奏。这也符合 RAII 之外的一种常用习惯：构造只完成资源和状态准备，start 时才真正对外服务。

2.3 handleRead()：一个事件循环批量收获连接

handleRead 是 Acceptor 的心脏，代码也不长，但信息量很大：

void Acceptor::handleRead() { loop_->assertInLoopThread(); InetAddress peerAddr; int connfd = acceptSocket_.accept(&peerAddr); if (connfd >= 0) { if (newConnectionCallback_) { newConnectionCallback_(connfd, peerAddr); } else { sockets::close(connfd); } } else { // EAGAIN 处理、EMFILE 处理等 } }

细心的人会发现：这里没有用 while 循环把所有连接全部 accept 干净，而是只 accept 了一次，然后立即把 connfd 交给回调。原因在于 muduo 的事件循环是 Level-triggered 模式——如果这次没 accept 完，监听 socket 的可读事件不会消失，下一轮循环会继续触发 handleRead，直到掏空为止。这种“一次处理一个”的写法巧妙避开了长循环，让回调链更可预测，也降低了单次事件处理的延迟。

如果 newConnectionCallback_ 为空，说明上层根本没人想要这条连接，那就直接 close 掉。这个分支很重要，因为在事件驱动模型里，事件来了不代表你有义务接收。

2.4 文件描述符耗尽：idleFd 技巧

如果系统 fd 被耗尽，accept 会返回 -1，errno 是 EMFILE（进程级 fd 耗尽）或 ENFILE（系统级 fd 耗尽）。这两个错误经常让人头大，因为你处于一个尴尬的处境：明明收到了新连接事件，却连一个 fd 都拿不出来。如果只是简单跳过，监听 socket 会一直可读，事件循环会像死循环一样反复触发 handleRead，CPU 直接被打满。

muduo 的解法非常巧妙，它维护了一个 idleFd_，初始化时打开 /dev/null 占住一个 fd 名额。当 accept 返回 EMFILE 时，先把 idleFd_ 关掉，腾出一个名额，然后立即调用 accept 拿到那个真正的连接 fd，再立刻把这个 fd 关掉——因为系统已经没资源了，这条连接注定活不下去，不如直接掐断让客户端重试，最后重新把 idleFd_ 打开占位。

if (errno == EMFILE || errno == ENFILE) { ::close(idleFd_); idleFd_ = ::accept(fd, NULL, NULL); ::close(idleFd_); idleFd_ = ::open("/dev/null", O_RDONLY | O_CLOEXEC); }

这个“占位 fd”的思路相当经典，我第一次看的时候愣了几秒才想明白：它并不试图真正处理这条连接，而是通过挪位的方式让内核认为“系统里还有 fd 可用”，从而完成一次 accept，再把这个注定无法被服务的连接干净地释放掉。这比直接忽略 EMFILE 要稳得多，至少事件循环不会空转。

3. 连接建立：从 accept 返回值到一条“活”连接

3.1 TcpConnection 的诞生现场

当 Acceptor 的 newConnectionCallback_ 被触发时，控制权已经转到了 TcpServer。TcpServer 内部维护着一个 connections_ 映射表，存着所有存活连接的 shared_ptr。对应逻辑大致是这样的：

void TcpServer::newConnection(int sockfd, const InetAddress& peerAddr) { // 构造连接对象，名字通常由 ip:port 拼接而成 TcpConnectionPtr conn(new TcpConnection(loop_, connName, sockfd, localAddr, peerAddr)); connections_[connName] = conn; conn->setConnectionCallback(connectionCallback_); conn->setMessageCallback(messageCallback_); conn->setWriteCompleteCallback(writeCompleteCallback_); conn->setCloseCallback(std::bind(&TcpServer::removeConnection, this, _1)); loop_->runInLoop(std::bind(&TcpConnection::connectEstablished, conn)); }

这里有几个设计决策值得咀嚼。第一，TcpConnection 是跑在哪个 loop 上的？如果 TcpServer 做的比较简单，那和 TcpServer 共用一个 loop；如果用了多线程模型，连接对象会被轮询分配到不同的 subloop 上。muduo 把“创建对象”和“激活事件”拆成了两步，对象构造在创建现场完成，而真正把 fd 注册到某个 loop 的 Poller 则通过 runInLoop 投递过去，这能避免跨线程操作 Channel 的竞态。

第二，连接对象在创建时进不了 connections_ 表？其实可以进，但要注意 map 中的 shared_ptr 是连接对象存活的根基。如果程序在 TcpConnection::connectEstablished 执行前触发异常，map 里还留着它，后面回调链也不会断，这是合理的防御策略。

第三，setCloseCallback 绑定到了 TcpServer::removeConnection。这意味着当一条连接走到关闭尽头时，TcpServer 会负责把它从 map 中移除，并安排最终的资源释放。

3.2 connectEstablished()：正式接入事件循环

TcpConnection 构造函数完成之后，状态是 kConnecting，但这个对象实际上还没有被 Poller 感知。真正让连接“活”起来的是 connectEstablished()：

void TcpConnection::connectEstablished() { loop_->assertInLoopThread(); assert(state_ == kConnecting); setState(kConnected); channel_->tie(shared_from_this()); channel_->enableReading(); connectionCallback_(shared_from_this()); }

connectEstablished 干了四件事：确认状态、把状态从 kConnecting 切换为 kConnected、把 Channel 与连接对象绑定、使能读事件。

先说 tie。TcpConnection 是一个继承自 std::enable_shared_from_this 的类，tie 的本质是让 Channel 持有连接对象的 shared_ptr，目的是保证在事件回调执行的整个窗口期内，TcpConnection 对象不会被析构。你设想这样一个场景：某条连接的读事件触发了，Channel 正在回调 handleRead，但业务层恰好在另一个线程把 map 里的连接对象清掉，如果 Channel 不持有强引用，对象在下一次回调前就被释放了，崩溃也就来了。tie 就是一道保险。

重点理解 enableReading 的时机：必须在连接建立后立刻做。因为 fd 刚被 accept 出来，内核里可能已经有数据在排队了，如果你太晚注册读事件，数据会一直积压在接收缓冲区里，虽然系统不会丢，但延迟和内存占用都会成为隐患。

3.3 状态机的第一次切换：kConnecting 到 kConnected

muduo 为 TcpConnection 定义了四个状态：

从 kConnecting 到 kConnected 的切换只发生在 connectEstablished 中。这个状态机的存在不是摆设：muduo 在 send() 时会检查当前状态，只有 kConnected 才允许发送数据；shutdown() 必须在 kDisconnected 之前完成，否则没有意义。

你可能想问：为什么不在 accept 之后就立即把状态设为 kConnected？原因还是“对象创建”和“事件激活”分离。TcpConnection 刚构造时，Channel 还没注册，如果此刻有断连事件到来，状态根本不匹配，断言会直接暴露程序逻辑问题。所以只能等 connectEstablished 用断言确认“你是从 kConnecting 过来的”，才允许进入 kConnected。

4. 优雅关闭连接：为什么不能直接 close

4.1 直接 close 的三个问题

很多人写网络程序时习惯在断开时直接调 close(fd)。如果只是处理错误或主动放弃一条烂连接，粗暴关闭完全可以，但如果你想“体面地结束”，直接 close 至少有三个问题：

第一，内核发送缓冲区里可能还有没发完的数据。close 会尝试把缓冲数据发送完，但过程不可控，你无法知道这些数据是否已经完整到达对端；而且 close 之后该 fd 立即被释放，即使还想用它对端后续的回包也完全做不到了。

第二，close 是原子式地同时关闭读写两个方向。但真实业务里，经常需要“先告诉对方我写完了，但还继续读对方的消息”，也就是半关闭语义。一次 close 把两条路都断了，应用层想做优雅协商就难了。

第三，TIME_WAIT 状态与 fd 复用。直接 close 后，主动关闭方的连接会进入 TIME_WAIT，端口短时间被占用；如果马上有新的客户端要连同一端口，就可能失败。虽然可以开 SO_REUSEADDR，但这只是缓解，不是解决。优雅关闭更关注的是“mark 一个明确的关闭意图”，而不是把资源扔给内核去善后。

4.2 半关闭：shutdownWrite 与“还能读”的状态

TCP 协议支持半关闭：一方调用 shutdown(fd, SHUT_WR)，内核会发送 FIN，表示“我不再写数据了”，但读方向仍然开放，还能接收对端的数据。对端收到 FIN 后，read 返回 0，即 EOF 标志。

muduo 将这套语义封装在 TcpConnection::shutdown 里：

void TcpConnection::shutdown() { if (state_ == kConnected) { setState(kDisconnecting); loop_->runInLoop(std::bind(&TcpConnection::shutdownInLoop, this)); } } void TcpConnection::shutdownInLoop() { // 只有在没有待写数据时才真正 shutdownWrite if (!channel_->isWriting()) { socket_->shutdownWrite(); } }

这里有一个关键的分支：调用 shutdown() 先把状态置为 kDisconnecting，然后投递到 IO 线程执行。shutdownInLoop 里判断 channel_->isWriting()，意思是如果此刻内核写缓冲区里还有排队的数据，那就不能立刻 shutdownWrite，否则数据会丢失。得先把数据发完，再关闭写端。

这就是“优雅”二字的真正含义：先确保数据完整送达，再发送 FIN，告诉对端“我把话讲完了，你可以安全地关闭了”。

4.3 关闭状态机：kDisconnecting 与延迟 shutdown

有了 kDisconnecting 状态，整个关闭过程就变得非常清晰。我们顺着主动关闭方的视角走一遍：

1. 业务层调用 conn->shutdown()。
2. 如果此时状态是 kConnected，切换为 kDisconnecting。
3. shutdownInLoop 执行：若当前没有写事件等待处理，立即 shutdownWrite 发送 FIN；若还有数据在写，则等待写事件处理完，再补刀。
4. 对端收到 FIN，read 返回 0，对端进入自己的关闭流程，最终对端 close(fd) 发出 FIN。
5. 主动关闭方收到对端 FIN，读事件返回 0，进入 handleClose，释放连接资源。

注意状态机的价值：kDisconnecting 保证“我正在往关闭的方向走，但还没走完”。在这个状态下，如果应用层不知好歹继续调 send，muduo 会直接拒绝，因为发送方向已经或即将关闭。反过来说，如果状态是 kConnected 且调用了 shutdown，但 IO 线程还没来得及执行 shutdownInLoop，此刻还有新的数据进来，业务依然可以读，这正好符合半关闭语义“我还能读你的消息”。

4.4 写缓冲未清空时，关闭如何自洽

前面提到 shutdownInLoop 只在 channel_->isWriting() 为 false 时才真正调用 shutdownWrite，但这里还有一个容易被忽略的细节：当 channel 正在写数据时，写完成回调 writeCompleteCallback_ 里，muduo 会再次检查状态是不是 kDisconnecting，如果是，就补发 shutdownWrite。

来看一下 handleWrite 的简化逻辑：

void TcpConnection::handleWrite() { if (channel_->isWriting()) { // 把 outputBuffer_ 中的数据写入 fd } if (outputBuffer_.readableBytes() == 0) { channel_->disableWriting(); if (writeCompleteCallback_) writeCompleteCallback_(shared_from_this()); if (state_ == kDisconnecting) shutdownInLoop(); } }

这么设计的巧妙之处在于：底层写事件消失后，应用明确知道“缓冲里的东西发出去了”，此刻才适合半关闭。如果你不看源码，很大概率会把 shutdown 和 shutdownWrite 当成一回事，结果就是“数据明明还没发完，连接却已经断了”，对端收到的数据不完整，产生难以排查的线上 bug。

从工程角度再强调一次：shutdown 是应用层的“关闭意图”，shutdownWrite 是底层的“写方向关闭动作”，两者之间隔着“把数据发完”这个关键步骤。 mtuo 的优雅正是在这里体现得淋漓尽致。

5. 连接断开后：清理、回调与资源释放全链路

5.1 handleClose：对端断开时本端怎么收场

被动关闭方收到对端的 FIN 后，读取事件返回 0，muduo 走的是 handleClose 这条分支：

void TcpConnection::handleClose() { loop_->assertInLoopThread(); assert(state_ == kConnected || state_ == kDisconnecting); setState(kDisconnected); channel_->disableAll(); closeCallback_(shared_from_this()); }

这里有三个动作：断言状态合法、把状态置为 kDisconnected、禁用所有事件，然后回调 closeCallback_。这个 closeCallback_ 在 TcpServer::newConnection 中被绑定为 TcpServer::removeConnection，也就是说，TcpConnection 自己不负责从 map 中把自己摘出去，它只是发出“我该被清理了”的信号，由 TcpServer 统一处理。

为什么要断言 state 是 kConnected 或 kDisconnecting？因为如果是 kConnecting 或 kDisconnected，说明这条连接可能还没建立就断开了，或者已经被处理过一遍，逻辑上属于重复关闭。断言把这类异常尽早暴露。

disableAll 之后，Channel 不再关注任何读写事件，fd 也不会再触发任何事件。但注意，此刻 fd 还没有真正 close 掉，因为连接对象还活着。真正的 close 发生在 connectDestroyed 或对象析构时。

5.2 removeConnection 与 connectDestroyed

TcpServer::removeConnection 的作用是把连接从映射表里摘除，并把它从事件循环上彻底卸载：

void TcpServer::removeConnection(const TcpConnectionPtr& conn) { loop_->runInLoop(std::bind(&TcpServer::removeConnectionInLoop, this, conn)); } void TcpServer::removeConnectionInLoop(const TcpConnectionPtr& conn) { size_t n = connections_.erase(conn->name()); EventLoop* ioLoop = conn->getLoop(); ioLoop->queueInLoop(std::bind(&TcpConnection::connectDestroyed, conn)); }

第一层 runInLoop 是为了保证 map 操作发生在主线程（TcpServer 的 loop）里；第二层 queueInLoop 是为了把 connectDestroyed 投递到连接实际所在的事件循环。为什么不能直接调用 connectDestroyed？因为 TcpConnection 的 Channel 挂在 ioLoop 的 Poller 上，对它的修改必须发生在 ioLoop 线程内，否则会有竞态。

connectDestroyed 做的事情和 connectEstablished 正好相反：先 disableAll、移除 Channel，再调用连接关闭回调，最后析构对象，fd 随之被 close。整套链路清晰且有秩序，你永远不会看到“fd 在 A 线程关闭、事件却在 B 线程被处理”的荒谬情况。

5.3 生命周期管理：shared_ptr、tie 与 Channel

连接对象的生命周期管理是 muduo 里最容易踩坑的点，也是初学者读源码时最容易懵的部分。这里我用自己的话理顺一遍：

• TcpServer 的 connections_ map 持有连接对象的 shared_ptr，这是对象存活的主根。
• Channel 通过 tie 持有一份连接对象的 shared_ptr，保证事件回调期间对象不会提前析构。
• 各个回调函数里如果持有 TcpConnectionPtr，也会在回调窗口期内延续对象生命。

关键在于：这样设计会不会造成内存泄漏？其实不会。TcpConnection 不持有指向自己的共享指针，Channel 持有的 tie 也只是临时的强引用。当 handleClose 把 state 置为 kDisconnected、TcpServer 把 map 中的条目 erase 掉之后，引用计数会降下来，等到 connectDestroyed 中 Channel 也解除引用，对象就在预期时间被析构。

你会问：那 map 里 erase 会不会导致对象马上析构，而 closeCallback_ 还在用 conn？不会，因为 closeCallback_ 本身拿着一个 TcpConnectionPtr 副本，这个副本会一直存活到回调返回。muduo 在这类细节上考虑得很细。我只想说，真等你自己在代码里因为 deref-after-free 焦头烂额时，就会回来感谢这种设计了。

6. 实操记录：验证连接的建立与优雅关闭

6.1 用一个最小回显服务做验证

光看源码容易“手里有锤子，满眼都是钉子”。我建议你本地起一个最小的回显服务，把 Acceptor 和 TcpConnection 这条链路完整跑一遍。代码骨架大概是这样（只需要验证用法，不用关心具体业务）：

class EchoServer { public: EchoServer(EventLoop* loop, const InetAddress& addr) : server_(loop, addr, "EchoServer") { server_.setConnectionCallback( [](const TcpConnectionPtr& conn) { if (conn->connected()) { LOG_INFO << "new connection"; } else { LOG_INFO << "connection closed"; } }); server_.setMessageCallback( [](const TcpConnectionPtr& conn, Buffer* buf, Timestamp) { conn->send(buf->retrieveAllAsString()); conn->shutdown(); // 回显完直接优雅关闭 }); } void start() { server_.start(); } private: TcpServer server_; };

这个 echo 服务收到一条消息后原样发回去，然后立刻调用 shutdown()。你会看到日志里依次出现 NewConnection、Message、Connection closed。这听起来很简单，但把日志级别开到 INFO，再盯着 TcpConnection 状态切换的过程，你会发现 shutdown 真的不是“说断就断”，而是跟着状态机一步步走完的。

6.2 调试与观察手段

验证连接建立后，真正值得花时间观察的是“优雅关闭到底关了什么”。我每次排查都会用三个工具：

第一，日志时间线。muduo 自带日志，把你的日志输出加上时间戳和线程号，重点关注 NewConnection、Message、Disconnection 三条日志的顺序和所属线程。如果某条连接的回调线程不对劲，一眼就能看出来。

第二，strace 系统调用。在服务端进程上跑 strace -f -e trace=network,close,shutdown -p PID，能看到 accept、shutdown、close 的真实调用顺序。当连接断开时，你会看到 shutdown(SHUT_WR) 在 close 之前被调用，这就是“优雅”二字在系统调用层面的证据。

第三，自己给 TcpConnection 的状态机打印加断点。在 connectEstablished、handleClose、shutdownInLoop 里各打一个断点，配合条件断点观察某个 fd，就能直观看到 kConnecting 到 kConnected 再到 kDisconnecting 的变化过程。看一圈下来，整个模型的理解程度会提升一个档次。

6.3 常见坑位速查表

最后把我实际踩过、也看别人踩过的坑整理进一张表，方便以后直接查。

写到这里，关于 muduo 连接管理的主干内容就梳理完了。我个人最深的体会是：Acceptor 和 TcpConnection 看似代码量不大，但它们把网络编程里最容易出错的三件事——事件注册时机、状态机转移、对象生命周期，全部做成了防御式设计。你在阅读时没必要死记每一个函数，只需要反复追问“为什么这个操作必须发生在某个线程里”“为什么这个状态必须先切换再执行动作”，就能把这套模型内化。如果你正在做自己的网络库或调业务层连接问题，建议开局先跑通一遍 echo 加 shutdown 的完整流程，再回头读这些代码，那种收获是最扎实的。