从select到epoll：多路IO复用与并发服务器实战解析

并发服务器和多路IO复用，这两个词放在一起琢磨过的兄弟应该都能猜到这篇聊什么。如果你刚接触网络编程，看到“并发”俩字就觉得得开一堆线程、上多进程，那这篇正好帮你把思路掰回来——高并发不是靠硬开线程堆出来的，一个进程里面同时盯住几百上千个连接，照样能处理得井井有条，这就是多路IO复用干的事。我前几年在做某跨平台系统的长连接网关时，被select的性能瓶颈折磨得不轻，后来切到epoll才算真正把并发量撑起来。这篇结合踩过的坑，把并发服务器的模型、多路IO复用的原理、以及从select到epoll的演进讲透，最后给一套可以直接上线的C语言epoll服务器Demo，跟着敲就能跑。

1. 并发服务器的三种姿势：多进程、多线程、多路IO复用

很多人一上来就纠结“我该用多进程还是多线程”，其实这俩都是并发的手段，但不是唯一的路子。在聊多路IO复用之前，得先把并发服务器的整体设计思路盘清楚，不然你后面看epoll的代码会懵。

逻辑上，并发服务器要解决的就一个问题：多个客户端同时连上来，每个连接都得有数据要收发，你怎么保证谁的数据都不漏、谁都不用干等？

第一种思路是多进程。每个客户端连接来了，fork一个子进程去伺候它，父子进程之间天然隔离，某个子进程崩溃了不会带崩整个服务。但代价也很明显：进程上下文切换开销大，内存开销翻倍，而且进程间要共享数据就麻烦得很。早年我用多进程写过一个模拟测试服务，连接一多CPU先撑不住，光切换上下文就吃掉不少资源。

第二种思路是多线程。每个连接一个线程，比进程轻量，线程间共享内存写起来也顺手。但线程多了之后，锁竞争、线程切换、栈空间占用都是隐性成本，而且“连接数上限=线程数上限”这个等式先天就有天花板。我自己试过一台普通服务器上开几千个线程，调度延迟和缓存抖动能把吞吐拉到没眼看。

第三种才是这篇的重点：多路IO复用。核心思想是一个线程管一堆连接，通过内核提供的机制同时监测这些连接上有没有可读、可写、异常事件。谁有事件就处理谁，没事件就歇着或者干别的。这样做的好处是线程数不随连接数增长，一台单线程的服务也能扛住上万连接，前提是业务计算本身不重。

说到底，多进程、多线程处理的是“并行计算”，多路IO复用处理的是“等待调度”。网络程序大部分时间都花在等数据、等写缓冲，与其让一个线程为了一个连接干耗着，不如让一个线程把一堆连接的等待动作一起交给内核。理解了这个定位，你就明白为什么真正的高性能网络框架底层清一色都是多路IO复用加事件驱动，而不是简单粗暴地一个连接一个线程。

1.1 为什么“一个连接一个线程”的模型扛不住大规模并发

展开说一下。传统阻塞式模型长这样：主线程accept到一个连接，就把这个socket丢给一个工作线程，线程里read()等数据，等到了就处理，处理完继续等。这个流程单看没有任何问题，问题出在“等”字上。

TCP连接是流式的，内核缓冲区里没数据的时候，read()会阻塞。你开一个线程等这个连接，这个线程就废在那里，除了占着CPU调度名额、占着线程栈的内存，啥也干不了。假设一个连接平均每秒只有一次数据交互，那这个线程有99%以上的时间都在空等。一万个连接就得开一万个线程，线程栈默认8MB的话，光栈空间就80GB，服务器直接先炸内存。

我刚开始做高并发的坑就是从这里踩起头的，总觉得线程池能兜底，但线程池只能控制活跃线程的峰值，解决不了“等待”的本质浪费。先把这个问题想明白，多路IO复用的价值品就出来了：等待的动作集中起来做，数据来了再干活，线程永远在处理有数据的连接。

2. 多路IO复用三件套：select、poll、epoll的原理与演进

多路IO复用不是epoll一个东西，它是从select、poll一路演进过来的。很多教材把这仨放一起讲，但没讲透为什么要有这一步一步的迭代。我按自己的理解，把它们的核心机制和演变逻辑串一遍。

先明确一个最简单的场景：你手里有一堆文件描述符，你希望内核帮你盯着，任何一个fd可读或可写的时候通知你。select是第一个被广泛使用的机制，它在Linux和Windows上都有，可移植性最强。

select的原理是把你要监视的fd集合交给内核，内核逐个扫描这些fd的状态，发现有就绪的就返回。调用时你会传三个集合：读集合、写集合、异常集合，内核会在返回时把这些集合原地修改成“哪些fd就绪了”，你再遍历一遍集合找到就绪的fd处理。这段逻辑听起来挺顺，但有两个致命伤。

第一，fd数量上限被写死了。select里用fd_set位图，固定长度，默认是1024，虽然可以通过改宏重新编译内核来扩大，但一般环境里1024就是天花板。第二，每次调用都要把fd集合从用户态复制到内核态，扫描完成后整个集合再复制回来，连接数多的时候，这个复制开销加上O(n)的线性扫描，性能会很感人。

poll是对select的一次升级，它把fd_set换成了pollfd数组，突破了1024的数量限制，理论上可以监视任意多的fd。但poll本质上还是线性扫描所有的fd，还是每次调用都要把数组拷进内核，连接数上去了照样线性变慢。它解决的是select的“数量瓶颈”和“集合修改后还要重新构建”的麻烦，没有从根上解决“每次都全量扫描”的效率问题。

真的要感谢epoll在Linux上把这个问题处理掉了。epoll的核心变化是：从“每次都全量扫描”变成了“事件回调登记”。 它不是让内核每回把所有的fd都翻一遍，而是你提前用epoll_ctl把关心的fd和事件注册进内核维护的一个事件表里，内核在fd真正的状态变化时，把就绪的fd加入一个就绪链表，你再用epoll_wait去取就绪列表就行。整个过程不用再每次拷贝所有fd集合，就绪的fd是被“挑出来”喂给你的。

用个生活化的类比：select和poll是“你每回问门卫，1000个房间里有没有人找你有事？门卫挨个敲门问一遍再给你回话”；epoll是“你跟门卫交代了，只盯着这几个房间，谁找你就直接带到跟前”。大量fd处于空闲时，epoll的优势体现得非常明显，这也是为什么Nginx、Redis这些高并发服务器在Linux上全部基于epoll或类似的机制。

2.1 边缘触发和水平触发的区别，为什么边缘触发要配非阻塞IO

只要聊到epoll，就躲不开LT（水平触发，Level Triggered）和ET（边缘触发，Edge Triggered）这两个模式。很多新手卡在这里，我用自己的话说一下。

水平触发是默认模式，心肠好：只要fd的缓冲区里还有数据没读完，epoll_wait就会一直通知你有这个事件。比如你一次只能读100字节，但缓冲里来了1KB，那epoll会反复提醒你“这个fd还有数据可读”，直到全部读完才消停。

边缘触发比较狠心：fd上状态发生变化的那一瞬间，它只通知你一次。比如缓冲从空变成有数据，这个“空到有”的边沿触发一次通知，之后哪怕缓冲里还积压着900字节没读，只要没有新的数据到达，epoll就不再通知你。这时候你就得一口气把数据尽可能读干净，否则数据会一直留在缓冲区里等下一次“新数据触发边沿”，容易造成数据延迟处理。

ET模式听着麻烦，但它有个巨大优势：它天然鼓励你把读逻辑写成“循环读直至EAGAIN”，配合非阻塞IO，一次事件处理把所有已经到达的数据全部读完，不会被LT模式下“每次事件只读一点、然后又触发一次事件”的反复骚扰困扰，能显著减少系统调用次数。Nginx就是切成ET模式下跑出极强性能的典型例子。

但是ET模式要求socket必须是非阻塞的，逻辑上很好理解：既然是边缘触发，一次通知你就想把缓冲读干，抱着阻塞IO去读，万一缓冲区里暂时还没数据呢？阻塞在那里，整个事件循环就卡死了，其他的连接全被拖下水。这个组合几乎是绑定关系，谁跟你说ET模式下还在用阻塞IO，那代码大概率是有雷的。

我自己的选型经验是：服务端主监听socket用LT，配合accept一次处理完当前所有连接，不容易漏连接；已连接的socket用ET，配上非阻塞IO，吞吐上比LT能明显感觉到顺。如果你刚开始用epoll，我建议先用LT把逻辑跑通，不要一上来就挑战ET加非阻塞的拆包粘包循环读，不然排查问题的难度是双份的。

2.2 一张表看懂select、poll、epoll怎么选

干脆把这几个核心模型的差别整理成一张表，项目选型的时候按需求对着表挑，比凭感觉靠谱。

这段表说白了就是三句话：连接量小、求跨平台，选select没毛病；连接量上来了而且确定在Linux环境里干，直接上epoll，别犹豫；至于poll，更像是select到epoll之间的过渡产物，新写的服务器代码已经没有理由再选它了。

3. 手写一个epoll并发服务器：从socket到事件循环

光说不练假把式，我写了几个版本的高并发服务器，最顺手的是下面这套C语言版的epoll实现。完整代码我放出来，然后逐段拆一下关键点，你照着敲一遍，基本就能把事件循环、缓冲区处理、连接管理这些概念焊死在脑子里。

先说一下整套代码的架构：主线程创建监听socket，设置非阻塞，注册到epoll实例中；然后进入事件循环，epoll_wait取就绪事件；即将accept的新连接直接加入epoll管理；业务数据通过读事件获取，通过写事件发送。核心就这么几大块。

c复制#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <sys/epoll.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <arpa/inet.h>
#include <fcntl.h>

#define MAX_EVENTS 1024
#define LISTEN_PORT 9000
#define BUFFER_SIZE 4096

// 把fd设置为非阻塞模式
static int set_nonblocking(int fd) {
    int flags = fcntl(fd, F_GETFL, 0);
    if (flags < 0) {
        return -1;
    }
    return fcntl(fd, F_SETFL, flags | O_NONBLOCK);
}

// 创建一个监听socket并设置好参数
static int create_listen_socket(void) {
    int listen_fd = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, 0);
    if (listen_fd < 0) {
        perror("socket");
        return -1;
    }

    // 允许地址复用，不然服务器重启时经常撞上TIME_WAIT
    int opt = 1;
    setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));

    struct sockaddr_in addr;
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = htonl(INADDR_ANY);
    addr.sin_port = htons(LISTEN_PORT);

    if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        perror("bind");
        close(listen_fd);
        return -1;
    }

    if (listen(listen_fd, 128) < 0) {
        perror("listen");
        close(listen_fd);
        return -1;
    }
    return listen_fd;
}

// 处理新连接，accept + 注册到epoll
static void handle_accept(int epoll_fd, int listen_fd) {
    while (1) {
        struct sockaddr_in client_addr;
        socklen_t addr_len = sizeof(client_addr);
        int client_fd = accept4(listen_fd, (struct sockaddr *)&client_addr,
                                &addr_len, SOCK_NONBLOCK);
        if (client_fd < 0) {
            if (errno == EAGAIN || errno == EWOULDBLOCK) {
                // 当前已经没有待处理的新连接了
                break;
            } else {
                perror("accept4");
                break;
            }
        }

        // 关闭Nagle算法，减少小包的等待延迟，适合频繁的小数据包交互
        int tcp_opt = 1;
        setsockopt(client_fd, IPPROTO_TCP, TCP_NODELAY, &tcp_opt, sizeof(tcp_opt));

        struct epoll_event ev;
        ev.events = EPOLLIN | EPOLLET;  // 读事件 + 边缘触发
        ev.data.fd = client_fd;
        if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, client_fd, &ev) < 0) {
            perror("epoll_ctl add");
            close(client_fd);
            continue;
        }
        printf("accept new client: %d, ip: %s\n",
               client_fd, inet_ntoa(client_addr.sin_addr));
    }
}

// 处理读事件，读到完整数据就原样写回（echo效果）
static void handle_read(int epoll_fd, int fd) {
    char buffer[BUFFER_SIZE];
    size_t total_read = 0;

    while (1) {
        ssize_t n = read(fd, buffer + total_read,
                         sizeof(buffer) - total_read - 1);
        if (n > 0) {
            total_read += n;
            if (total_read >= sizeof(buffer) - 1) {
                // 读满了，先处理一次当前数据，避免缓冲区溢出
                break;
            }
        } else if (n < 0) {
            if (errno == EAGAIN || errno == EWOULDBLOCK) {
                // 非阻塞情况下数据读完的标志
                break;
            } else {
                if (errno == ECONNRESET) {
                    // 客户端复位连接
                }
                close(fd);
                return;
            }
        } else {
            // EOF，客户端关闭连接
            close(fd);
            return;
        }
    }

    if (total_read > 0) {
        buffer[total_read] = '\0';
        // 这里简化处理成原样回显，生产环境替换成业务解析
        send(fd, buffer, total_read, 0);
    }
}

int main(void) {
    int listen_fd = create_listen_socket();
    if (listen_fd < 0) {
        return -1;
    }

    int epoll_fd = epoll_create1(0);
    if (epoll_fd < 0) {
        perror("epoll_create1");
        return -1;
    }

    struct epoll_event ev;
    ev.events = EPOLLIN | EPOLLET;
    ev.data.fd = listen_fd;
    if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, listen_fd, &ev) < 0) {
        perror("epoll_ctl listen");
        return -1;
    }

    struct epoll_event events[MAX_EVENTS];

    printf("epoll echo server start on port %d\n", LISTEN_PORT);

    while (1) {
        int n = epoll_wait(epoll_fd, events, MAX_EVENTS, -1);
        if (n < 0) {
            if (errno == EINTR) {
                // 被信号中断，重新进入等待
                continue;
            }
            perror("epoll_wait");
            break;
        }

        for (int i = 0; i < n; i++) {
            int fd = events[i].data.fd;
            if (fd == listen_fd) {
                handle_accept(epoll_fd, listen_fd);
            } else if (events[i].events & EPOLLIN) {
                handle_read(epoll_fd, fd);
            } else if (events[i].events & (EPOLLERR | EPOLLHUP)) {
                // 对端异常或挂断，直接关闭连接
                close(fd);
            }
        }
    }

    close(epoll_fd);
    close(listen_fd);
    return 0;
}

这套代码的骨架在实战里非常经典，我把关键的部分拆开讲一遍。

3.1 监听socket为什么要设非阻塞，listen队列满了会怎样

代码里用了socket()的SOCK_NONBLOCK标志，还有accept4函数而不是accept，其实都在干同一件事：尽力保证accept不阻塞。有人问，accept阻塞着等连接到来不好吗？问题在于事件循环是单线程的，如果accept阻塞了，整个服务就卡死了，所有已连接客户端的读写都会停下来等你accept返回。所以必须让accept是非阻塞的，配合while(1)循环把当前已经排队的连接全部处理完。

说到这个就扯出一个隐藏问题：**listen的backlog参数别太大。**很多教程说“设大点增加容量”，但backlog主要控制的是内核为监听socket排队的已完成连接数。太大了确实能多顶一会儿，但配合非阻塞accept时，如果队列里的连接一直没被取走，新来的连接在内核层面就直接超时或者被丢弃了。还有TCP_DEFER_ACCEPT这种参数可以调，能让accept在客户端真正发数据后才返回，减少空连接占着fd的情况，不过我一般不在新手Demo里加，容易把调试搞复杂。

3.2 事件循环里的EINTR信号中断，很多人第一版都没处理

代码里有一行不起眼但很关键的逻辑：

c复制if (n < 0) {
    if (errno == EINTR) {
        continue;
    }
    ...
}

epoll_wait被信号打断时返回-1并把errno置成EINTR，这是非常常见的现象。比如你连着一个调试器，或者进程收到某些信号，epoll_wait那一觉醒过来发现自己被叫醒了，但实际没有fd就绪。如果你不处理EINTR直接break退出循环，你的服务器会在一次看似无关的信号之后莫名其妙地挂掉。我第一次上生产的时候就吃过这个亏，服务跑着跑着自己没了，排查半天发现是监控脚本给进程发信号探活，把epoll_wait搞EINTR了。

看到这你可能有个疑问：EINTR发生了，我只是continue重新进入epoll_wait，那些业务怎么办？答案是没影响，因为epoll_wait被中断只是意味着这次“等”没等到就绪事件，监听的fd都还好好的躺在事件表里，下次调用epoll_wait还是能看到它们的状态，不会丢事件。

3.3 写事件没接好，服务端写不出去也要管

上面这个Demo只处理了EPOLLIN，也就是读事件，很多第一次接触epoll的人会忽略写事件，这会导致一个隐蔽的问题：当socket发送缓冲区满了，send返回EAGAIN，你的数据就堵住了。 客户端接收慢、网络拥塞、发送数据量一大，这个问题立刻暴露。

正确做法是给每个连接维护一个发送缓冲队列。send发现写不进去的时候，把剩余数据挂到发送队列里，同时给这个fd注册EPOLLOUT事件；等到epoll_wait上报EPOLLOUT，说明内核发送缓冲区有空间了，再把队列里的数据继续发；发完后移除EPOLLOUT，恢复正常写路径。

这套逻辑写起来比Demo多一点工作量，但属于高性能服务器的标配。边缘触发下，发送缓冲区的处理尤其要小心：EPOLLOUT触发一次，你要尽量在这一次事件里把队列里的数据发完或者处理到EAGAIN，否则缓冲满的时候内核也会一直触发EPOLLOUT的边沿，空转起来很浪费CPU。

4. 从单线程epoll到多线程协同：三种常见并发架构

我上面给的Demo是单线程事件循环，能扛的并发量已经不少了。但真实业务不可能只有echo，请求里往往带着业务逻辑、数据库访问、第三方调用，这些操作耗时长了会把事件循环卡住，拖慢所有连接的响应速度。所以实践中得把业务处理从IO事件循环里拆出来，常见的架构有三种。

第一种：单线程事件循环加线程池，串行处理业务。 主线程负责epoll_wait和收发数据，收到完整请求后丢给工作线程池处理，处理完把响应通过队列送回主线程发送。优点是结构简单、没有锁竞争问题，缺点是一个慢业务会把后续请求排队拖住，响应时间可能出现毛刺。适合业务普遍很快的场景，比如简单的JSON接口服务。

第二种：多线程事件循环，每个线程一个epoll实例。 这种方式先把监听socket放入每个线程的epoll里，连接来了由其中一个线程accept，然后根据负载均衡策略把新连接分配到某个线程的epoll中。每个线程维护自己的连接集合，天然把锁开销降到很低。这种方式适合连接数巨大且每个连接持续活跃的场景，很多高性能网关就是这么做的。不过要注意：跨线程关闭连接时，得通过事件或队列通知对应线程操作socket，不要去别的线程里直接close同一个fd。

第三种：主从Reactor模式。 主线程只负责accept，accept出来的连接按规则分发给从线程的事件循环，从线程负责该连接后续的收发和业务。Redis的单线程模型不算这个，但很多网络框架都会把IO线程和业务线程彻底分开，IO线程管收发，少做业务；业务线程池管计算，不做网络I/O。某种开发项目里我把业务线程池引入后，同样是单线程epoll，吞吐翻了三倍左右，原因就是业务计算不再占用事件循环的时间。

选型的时候没有银弹，得先判断你的瓶颈在IO还是计算。连接空闲多、数据流量小，第一种就够用；连接密集且每个连接流量大，第二种更稳；混合负载，第三种最能顶出性能来。我在做一个模拟项目时，负载从纯echo切到带JSON解析的业务逻辑后，单线程事件循环直接从每秒3万请求掉到几千，引入业务线程池才拉回来，这个坑很典型，分享出来当参考。

4.1 线程池里业务处理要注意的隐藏雷区

线程池引入之后，很多人都会栽在同一批坑里。第一个坑是线程安全地管理fd。业务线程要把响应数据发回去，但它不能直接去close这个fd，因为主线程可能同时在这个fd上做epoll_ctl，两个线程操作同一个fd容易并发问题。正确的姿势是业务线程只把要发送的数据封装成一个任务，交给IO线程去做实际的send和close，做到fd的所有权始终归属IO线程。

第二个坑是任务队列成为新瓶颈。线程池内部的任务队列如果无界，请求堆积时内存会暴涨；如果队列满，就要定义好拒绝策略，是阻塞等还是有损丢弃。实践当中我倾向于显式给队列设上限，配合监控告警，宁可拒绝一部分请求也不让内存先爆炸。

第三个坑是慢业务把线程池占满。线程全都被慢查询堵着，快请求也进不来。解决思路是把不同类型的业务拆开用不同的线程池隔离，或者给慢业务单独设队列和超时时间，避免相互拖累。这几个坑不像并发模型选型那么宏观，出了事才知道疼，写在这里供各位提前避雷。

5. 实战排查：epoll服务常见的5个故障和定位方法

一下给出每个正常运行的epoll服务器都迟早会用到的排查经验。这些都是我自己或者身边同行踩过的坑，整理成速查表，顺手把定位思路也写出来。

这里面最隐蔽的是fd复用的问题。TCP连接close后，这个fd的编号可能很快被新连接复用。如果你旧的epoll事件里还残留着这个fd的引用，又不做清理，新连接上来后你可能会拿着上个连接的状态去处理，轻则业务错乱，重则直接把新连接误关掉。所以每次close fd之前，强制先做一次EPOLL_CTL_DEL，然后等epoll_wait把该事件清除干净后再关。有些讲究的代码还会在事件结构体里放一个“是否已失效”的标记，双重保险。

5.1 连接被对端重置了，服务端会不会崩

客户端直接拔网线、程序崩溃，TCP连接不会正常收到FIN，而是会触发RST。服务端在read时得到ECONNRESET错误，这个错误要单独处理。代码里我专门判断了这个错误，很多人好奇为什么不是直接当普通错误处理。

ECONNRESET语义是“对端有数据要发，但它的接收缓冲区已经没了”，说明对端已经死了。这个fd后续不会再有什么正经数据过来，留着只会占资源，所以直接close。但注意：close这个fd之前，你这边的发送缓冲区里如果还有未发送的数据，会被一起丢掉的。 如果业务上需要保证这部分数据送出去，得把close动作换成先shutdown(SHUT_WR)，等残余数据发完再close，这个细节是生产环境里老手和新手的分水岭。

6. 最后的实战体会：epoll配置内核参数怎么调，以及别把epoll神化

写了这些，最后分享两个长期实践得出的小经验。

一个经验是关于reactor模型的“惊群问题”。多线程epoll监听同一个listen fd时，一个连接进来，可能多个线程同时被唤醒去accept，虽然有内核机制改善，但业务上还是要尽量避免简单粗暴地多个线程抢同一个监听fd。更稳的方案是主线程只负责accept，accept完之后按负载均衡算法把连接分给子线程。如果确实要多个线程同时监听，建议把accept的处理加上锁，或者用SO_REUSEPORT让内核做负载均衡。这个细节在连接量极大的网关场景里尤其明显。

另一个经验是epoll不是万能的钥匙。它解决的是IO等待的效率问题，不解决业务逻辑的计算效率问题。如果你的代码里到处都是序列化反序列化、数据库操作、字符串处理，就算epoll用出花来，照样给业务拖垮。复杂的线上系统往往是epoll、线程池、消息队列、缓存一起来，各管一段。新手学习的时候一定要把“并发”理解成一套组合拳，不是上了一个神器就高枕无忧。

内核参数方面，服务器压力大的时候我会顺手看这几个值：net.core.somaxconn决定监听队列上限，默认128可能不够；fs.file-max决定进程能开多少fd；net.ipv4.tcp_fin_timeout影响TIME_WAIT回收速度。这些不是开了就“越大越好”，得结合机器内存和业务情况调整，盲目调大的后果往往是内存被半开连接吃满。

我自己回想做并发服务器的过程，最值钱的不是某天突然会用epoll了，而是把阻塞、非阻塞、事件驱动、边缘触发和水平触发这组概念彻底理顺的那天。如果你看完这篇能以“事件”为线索，把一套服务器从socket到事件循环再到业务线程串起来，这5000字就没白写。 建议直接把代码拉下来跑一跑，先跑通echo，再改成转发，然后加线程池，每抬一级都会有新的感觉。这些代码在真实项目里滚动过，遇到的问题也都是真实存在的，跟着踩一遍，比背一百个面试题都管用。