每年面试季我都会把“TCP 三次握手与四次挥手”这道题放在技术面第一轮。问了这么多年我越来越确定一件事这道题根本不是送分题。十个候选人里八个能把流程背得一字不差——“客户端发SYN服务端回SYNACK客户端再回ACK”甚至能顺手画出状态迁移图。但只要我追问一句“为什么是三次而不是两次”一半以上的人会愣住。更让我意外的是很多有几年工作经验的人面对“挥手为什么是四次”“TIME_WAIT为什么要等2MSL”这类变体追问时依然答不到点子上。问题不在记忆力而在他们把这套协议当成了八股文没有真正理解它解决的是什么问题。这篇文章我想换个思路不从状态机出发而是从“为什么”出发把三次握手和四次挥手的完整逻辑链条拆开再结合我实际抓包和线上排障的经验讲讲面试官在追问时真正想听到的东西。1. 题目人人会背但面试官到底在考察什么1.1 三次握手与四次挥手背后的能力模型我面试时喜欢先从这道题开场不是因为我懒而是因为它天然覆盖了一个网络工程师或者说后端开发者最核心的几项能力。第一项是网络分层的基本功。问到TCP你至少得清楚它属于传输层承上启下地连接着应用层HTTP、DNS这类协议和网络层的IP。面试官想听你自然地提到“TCP是面向连接的、可靠的、基于字节流的传输层协议”而不是机械地背书。第二项是理解“可靠性从哪来”。TCP的可靠并不是拥有某条神奇通道而是通过确认、重传、排序、流量控制这些机制堆出来的。三次握手和四次挥手恰恰是这些机制最浓缩的体现。你如果能说清楚“每一次握手确认了谁的发送能力、谁的接收能力”说明你真的理解了可靠连接的本质。第三项是对异常场景的敏感度。很多候选人只记得流程一被问到“如果第三次握手丢包会怎样”“为什么要TIME_WAIT”就答不上来。而线上故障排查看的最多的恰恰就是这些异常场景连接建不起来、连接卡在某个状态、连接被对端重置。所以这道题表面考协议实际考的是你对一个复杂系统在正常路径和异常路径上的综合把握能力。这也是为什么几乎所有公司的面试题库里都有它。1.2 面试官追问的四个层级同一个问题不同水平的候选人会自动分层。我把这些年比较典型的追问路径整理了一下层级追问方向典型问题考察意图第一层背流程三次握手的过程是什么有没有基础记忆第二层讲原理为什么是三次而不是两次是否理解确认机制第三层追状态SYN_SENT、CLOSE_WAIT、TIME_WAIT各自何时出现是否熟悉状态迁移第四层问工程SYN Flood怎么防御TIME_WAIT太多怎么处理是否具备排障思维说实话能稳定通过前三层的候选人已经超过平均水平了。能到第四层的基本就是我要的人。因为到了这个层级面试官和候选人是在用同一套语言讨论问题而不是在一问一答地检验记忆力。2. 三次握手拆解从SYN到ACK的完整逻辑链2.1 第一次握手SYN包为什么要携带一个随机序列号第一次握手客户端向服务端发送一个SYN包首部的SYN标志位被置为1同时携带一个序列号通常记作seqx。很多人背到这里就停了但这里其实是最值得展开的地方。序列号x不是随便定的它叫ISNInitial Sequence Number初始序列号。在Linux系统中它不是固定的0而是通过一个随时间变化的算法加上随机扰动生成的。为什么不能固定因为序列号的核心作用有两个一是给字节流编号做排序和去重二是让接收方能识别出哪些是旧连接的残留报文。打个比方如果你和我之间传纸条每张纸条上都有一个编号同时我们约定“编号越大越靠后”。如果每次重新开始对话都从1编号万一上一轮对话里有一张迟到的纸条恰好也写着1我就会把它当成新一轮的纸条整个顺序就全乱了。ISN随机化正是为了降低这种新旧报文串扰的概率。所以第一次握手的本质是客户端告诉服务端——“我要和你建立连接我的初始字节编号是x请你准备好接收从我这里发出的数据。”2.2 第二次握手SYNACK组合包的真实含义服务端收到SYN后如果愿意建立连接会同时设置SYN和ACK两个标志位回复一个SYNACK包。这个包携带两个关键信息自己的初始序列号seqy以及对客户端seq的确认号ackx1。注意这里的细节很多人会忽略ackx1的准确含义。它不是在说“我收到了你的第x个字节”而是在说“我期待你的下一个字节编号是x1”。TCP的确认号是累计确认表示的是期望收到的下一个字节序号这跟你网购时“已签收第5件”不是一回事更像是在说“你从第6件开始发我就接着收”。服务端的SYNACK同时表达了三层意思第一我收到了你的SYN你的发送方向是通的第二我这边也准备好发送数据了我的初始编号是y第三请你开始发送字节编号为x1的数据。这其实也在暗示TCP是全双工的两条方向独立的通道需要分别建立。第二次握手就是服务端在为“服务端到客户端”这个方向做宣告和确认。2.3 第三次握手ACK的作用是完成双向确认客户端收到SYNACK后回复一个包ACK标志位置1确认号acky1同时自己的序列号seq变成x1。第三次握手的重要之处在于它完成的是服务端方向的确认。经过前两次握手客户端已经确认了自己能发、服务端能收服务端也确认了自己能发、客户端能收不对严格来说服务端此时还不确定“自己的SYNACK是否成功送到了客户端”。如果客户端没收到SYNACK它就不会发第三次ACK服务端就只能在SYN_RECV里苦等。所以这最后一个ACK本质上是给服务端吃的那颗定心丸。三次握手结束后双方才同时确认了四个事实我能发你能收你能发我能收。这时连接才真正进入ESTABLISHED状态。这也是为什么第三次握手的ACK包一旦丢失服务端会超时重发SYNACK而不是双方就此进入ESTABLISHED——因为在服务端视角自己的宣告还没得到确认连接就不算真正建立。2.4 追问停在这里为什么不能是两次握手这个问题几乎每次必问。我的建议是别背标准答案直接把场景推演出来。如果只有两次握手客户端发SYN服务端回SYNACK服务端就认为连接建立了会立刻分配资源、进入ESTABLISHED状态开始等待数据。问题是客户端收到SYNACK之后才知道连接建立但服务端并不知道这个SYNACK到底有没有到达客户端。考虑一个更危险的情况网络中滞留了一个很久以前发出的SYN包因为网络延迟现在才到达服务端。服务端收到后回了一个SYNACK然后开始苦苦等待永远不会来的数据。客户端根本没有发起连接的意图却因为一个过期报文在服务端留下了一个半开的废连接占用着内存和端口资源。这就是两次握手的致命缺陷——它让服务端在无法确认对端是否真的在线的情况下就提前进入了可用状态。三次握手则多了一道“反向确认”的关卡客户端没确认服务端就不建立完全体连接最多停留在SYN_RECV的超时等待里合法握手和垃圾报文的命运也因此被区分开。2.5 再多问一步为什么不用四次握手这个问题面试官不常问但如果你能在回答里主动提一句“其实握手不需要四次”会显得思考更完整。因为三次握手已经在信息上达到了闭环。第一次握手让服务端确认客户端的发送意愿第二次握手让客户端确认服务端的发送意愿第三次握手让服务端确认客户端的接收意愿。所有需要双向确认的信息都到位了第四次握手并不会增加任何新的确定性。有人会说“客户端再回一个确认服务端不就更放心了吗”可第三次就是那个确认。再多一次只是把同样的信息重复一遍徒增一个RTT的时延。要知道每多一次握手建立连接的耗时就会增加一个网络往返周期这对延迟敏感的业务是不可接受的。所以协议设计者选了“最少但完整”的三次而不是冗余的四次。3. 四次挥手拆解半关闭、FIN与2MSL的真相3.1 挥手全程的状态流转如果说三次握手是慢慢建立一条双向通路四次挥手就是把这条双向通路一边一折地拆除。默认场景下客户端主动发起关闭完整过程是这样的客户端发FIN包序列号为u表示“我的数据发完了不会再发了”同时进入FIN_WAIT_1状态。服务端收到FIN后回一个ACK确认号acku1然后进入CLOSE_WAIT状态。这里体现的就是TCP的半关闭特性——客户端关了发送方向但服务端可能还有数据要发接收方向仍然保留。服务端在CLOSE_WAIT里处理完剩余数据发送自己的FIN包序列号为v然后进入LAST_ACK状态意思是“我这边也发完了准备关闭”。客户端收到FIN后回一个ACK确认号ackv1然后进入TIME_WAIT状态。服务端收到这个ACK后关闭客户端则在TIME_WAIT里等上一段时间再彻底关闭。看到没有四个包两个方向各一对FINACK。这跟握手本质上是同一种模式只不过拆的时候每个方向都要单独确认。3.2 四次 vs 三次FIN和ACK为什么不一定能合并很多人在这一点上很困惑既然挥手时服务端是先回ACK、再发FIN为什么不合并成一次学握手里的SYNACK关键在于半关闭。TCP允许一端在完成发送任务后关闭发送方向同时继续接收数据。服务端收到客户端的FIN只是宣告“你不再发数据了”但服务端自己可能还有一批数据没发完比如一个响应报文还在传输中。它必须等那些数据都发完才能发自己的FIN。所以在绝大多数场景里FIN和ACK天然是分开的两个包各自的时机不同。只有在一种特殊情况下它们能合并服务端收到FIN时恰好也没有数据要发这时它可以立刻一起回FINACK整个挥手过程就会从四步缩成三步。我在抓包时经常见到这种情况尤其是在测试环境里客户端访问一个返回空响应的简单服务时挥手常常只有三个包。所以严谨的说法应该是“TCP挥手通常为四次双方恰好都没有待发数据时可以合并为三次”。3.3 主动关闭方为什么还要等2MSL四次挥手不是踢完了最后一脚球就散场主动关闭方踢完最后那个ACK后还要在场边独自等待2MSL才能离场。这个等待就是TIME_WAIT状态。2MSL指的是两个报文最大生存时间MSL是Maximum Segment Lifetime报文在网络上存活的最长时间。TCP协议规定IP报文有生命周期过了这个时间还没到达就会被丢弃。TIME_WAIT中的2MSL指的是一去一回两个方向上可能残留报文的最大时间。这样做有两个目的。第一确保最后一个ACK能被服务端收到。如果这个ACK在网络中丢失了服务端因为一直没收到确认会超时重发FIN。此时客户端还处于TIME_WAIT听到重发的FIN后可以再补发一个ACK。如果客户端收到FIN后立刻关闭那重发的FIN就无人应答了服务端会一遍遍重传直到放弃甚至误以为客户端掉线。第二让旧连接的报文在网络上彻底消失。TIME_WAIT持续2MSL足够让前一个连接里所有挣扎在途的报文全部消亡。否则一条新连接刚好复用了同一个四元组接收方可能会把一个迟到的旧数据包误当成新连接的数据造成不可预知的结果。所以TIME_WAIT不是无意义的空等它是用一段确定的时间换取了确认可靠性和新旧连接隔离的确定性。3.4 最后丢包怎么办挥手失败时的核心兜底顺着上面的逻辑可以推演出挥手丢包的种种表现。如果客户端的最后一个ACK丢了服务端会重复发送FIN。客户端因为还在TIME_WAIT会再次响应ACK这个循环会持续到服务端重传次数耗尽或者成功收到ACK为止。如果服务端的FIN丢了客户端会一直停留在FIN_WAIT_2状态等待一个永远不来的FIN。这个过程同样由内核的超时机制兜底最终可能关闭连接并释放资源。在实际业务里CLOSE_WAIT堆积是最常见的问题。服务端收到客户端的FIN后进入了CLOSE_WAIT正常情况下应该很快处理完业务数据然后发FIN但如果应用程序忘记调用关闭接口或者代码逻辑阻塞在某个地方没进行收尾处理服务端就会一直停在CLOSE_WAIT大量连接堆积最终导致资源耗尽。每次有人拿着“CLOSE_WAIT暴涨”的截图来问我我第一反应都是先查应用层为什么没有关闭连接而不是急着调内核参数。4. 从握手到排障面试官后续追杀的高频追问4.1 SYN Flood半连接队列被打满之后三次握手给安全带来一个天然的瞄准点。攻击者可以伪造大量源地址向目标服务端发送SYN但永远不完成第三次握手。服务端的每个SYN都会占用一个半连接队列的位置这些半开连接就像永远不付款的订单一直占着仓库的资源。半连接队列也就是SYN队列专门存放SYN_RECV状态的连接与之相对应的是全连接队列也叫Accept队列存放已完成三次握手等待应用层accept的连接。SYN Flood攻击的核心效果就是把半连接队列塞满让正常用户的SYN根本排不上队表现为“服务不可用”。防御手段里最典型的是SYN Cookie。服务端不老实为每个SYN分配队列资源而是把连接信息加密编码成一个Cookie放在SYNACK里回给客户端等客户端回ACK时再验证Cookie。这样攻击者的半连接不再吃资源合法连接又能正常建起来。这个机制如今在内核里默认就是开着的。这个追问在面试里的价值在于如果你只背“三次握手是SYN、SYNACK、ACK”你是无论如何也推导不出攻击原理和防御思路的只有真正理解了吗为什么服务端需要为每个SYN停留在一个半连接状态才能理解为什么队列会被打满又为什么Cookie能化解这个矛盾。4.2 握手超时重传内核是怎么替应用层兜底的握手过程中如果某个包丢了怎么办TCP没有直接放弃而是启动了重传机制。比如第一个SYN发出去后客户端迟迟没有收到SYNACK。一般情况下1秒后客户端会重发SYN之后等待时间翻倍2秒、4秒、8秒……呈指数退避直到重传次数达到上限。这就是为什么你看到一个“连接超时”的报错往往不是瞬间出现而是要诡异地等上好几秒甚至几十秒。第三次ACK丢失时服务端那边则会在SYN_RECV状态反复重发SYNACK。这里有个很容易混淆的知识点向一个没监听端口的地址发SYN会收到RST表现为“Connection refused”秒拒向一个有监听但网络丢包的地址发SYN则是沉默表现为“Connection timed out”干等。面试里如果你能顺口把这两个表现区分开会非常加分——因为能区分“被拒绝”和“超时”说明你真的懂RST和重传是两套完全不同的机制。4.3 TIME_WAIT堆积短连接业务的头号痛点线上问题上TIME_WAIT比CLOSE_WAIT更容易引起警觉。TIME_WAIT出现在主动关闭连接的一端频率最高的场景是客户端或者更常见的是处在流量入口位置的代理和负载均衡。如果一个服务大量使用短连接每处理完一次请求就断开一条连接那么服务端一侧会堆积大量TIME_WAIT持续约60秒。单看状态数量并不致命真正致命的是另一层风险TIME_WAIT期间同一四元组不能被复用一个服务对外连接数量有限如果连接端口耗尽新请求就只能排队或者失败。解决思路分两个层次。第一层是治本让客户端复用连接用长连接替代短连接减少断开频率这是我最推荐的方式。第二层是调参数比如开启tcp_tw_reuse它允许客户端在特定条件下复用处于TIME_WAIT的端口前提是对端也要支持TCP时间戳并且只在主动发起连接的一侧有意义。坦白讲这些参数不是万能药如果在不理解的前提下乱开反而可能引出时序错乱的新问题。面试时能把“为什么要谨慎”说出来比我听到“把TIME_WAIT改成0”之类的说法要高出一个段位。4.4 粘包拆包与Nagle字节流模型引发的变体题面试官经常会把粘包拆包跟三次握手放在同一个话题里聊。表面上是两个问题内核其实是一个TCP是字节流协议没有消息边界。三次握手之后客户端连续发送两个业务报文“AAA”和“BBB”接收方可能一次性读到“AAABBB”也可能分几次读到各种片段。不是TCP故意要拼在一起而是它只保证字节的顺序和完整性不负责帮你划出每条应用消息的边界。就像一条河流水是连贯的河面上飘的每一件货物之间的距离物流公司不管发货方和收货方自己得约定。解决方式也很固定要么在每个消息前加长度字段用4个字节标记后面内容的长度要么用特殊分隔符切分要么干脆固定长度。设计应用层协议时这是基本功。和粘包经常一同出现的还有一个名字叫Nagle算法。它的初衷是减少网络上小报文的个数把多个小数据攒一起再发。这对交互性要求高的场景几乎是灾难所以很多框架默认会开启TCP_NODELAY来禁用Nagle让数据立即发送。被问到粘包时主动关联一下Nagle能看出来你对“传输效率与实时性如何取舍”是有概念的。4.5 TCP Keep-Alive与HTTP Keep-Alive最容易偷换概念的一题这道题出现得更隐蔽很多面试官会故意把TCP Keep-Alive和HTTP Keep-Alive放在同一句话里看你会不会踩坑。TCP Keep-Alive是传输层的机制作用是在连接空闲一段时间后主动发送探测包确认对端是否还活着。默认情况下它属于可选能力Linux的默认空闲时间是2小时大多数业务场景其实感知不到它的存在。它解决的是“死链检测”问题。HTTP Keep-Alive是应用层的机制也叫HTTP长连接作用是在一条TCP连接上连续传输多个HTTP请求和响应避免频繁握手挥手带来的开销。它解决的是“连接复用”问题。两个名字长得像位置和作用完全不同。面试时你不需要说得特别复杂只要先跟面试官确认“你说的Keep-Alive是指传输层的还是应用层的这两个不一样”然后分别展开就足以证明你没有把概念混成一锅粥。5. 抓包验证一次握手与挥手实操演示的完整过程5.1 实验环境与命令准备背了这么多不如亲手抓一次包。我在给新人培训时总是强调只要能自己抓到一次三次握手和四次挥手那些状态名就会从纸面上的字母变成看得见摸得着的时间线。准备方法很简单一台Linux机器装上tcpdump和netcat。Windows机器也可以用Wireshark抓但命令行下用Linux最直观。开三个终端。第一个终端起抓包sudo tcpdump -i lo tcp port 8080 -w handshake.pcap第二个终端起服务端nc -l 8080第三个终端发起连接curl http://127.0.0.1:8080/这样会得到一个最小的TCP会话。等curl执行完在抓包终端按CtrlC结束抓包然后读取结果tcpdump -r handshake.pcap -nn5.2 三次握手抓包逐行解读正常抓包结果里前三行会是这样IP 127.0.0.1.12345 127.0.0.1.8080: Flags [S], seq 123456789, ... IP 127.0.0.1.8080 127.0.0.1.12345: Flags [S.], seq 987654321, ack 123456790, ... IP 127.0.0.1.12345 127.0.0.1.8080: Flags [.], ack 987654322, ...第一行是SYNseq是一个很大的随机数。第二行是SYNACK注意它同时回了一个新seq和自己的ack——ack等于客户端的seq加1。第三行是纯ACK带上了对服务端seq的确认。这里有个很坑的细节。Wireshark默认开启“Relative Sequence Numbers”把seq显示成0、1这种小数字方便人阅读但也很容易让人误以为初始序列号就是0。看绝对抓包数据时seq其实是一长串随机数。如果你在面试里主动提这一句“抓包工具默认做了相对序列号转换实际ISN是随机的”面试官通常会眼前一亮。验证时也可以在Wireshark里关掉视图偏好里的相对序列号选项立刻就能看到原始序列号。5.3 四次挥手抓包逐行解读连接建立并传输完数据后curl进程会主动关闭连接。抓包末尾会出现类似四行内容IP 127.0.0.1.12345 127.0.0.1.8080: Flags [F.], seq 123, ack 456, ... IP 127.0.0.1.8080 127.0.0.1.12345: Flags [.], ack 124, ... IP 127.0.0.1.8080 127.0.0.1.12345: Flags [F.], seq 456, ack 124, ... IP 127.0.0.1.12345 127.0.0.1.8080: Flags [.], ack 457, ...注意这里的第一行是FINACK第二行是ACK第三行又是FINACK第四行是ACK。FIN包为什么常带ACK因为数据发送过程本身会产生确认号FIN包需要捎带传输过程中尚未确认的字节信息。这又印证了前面说的挥手常被说成四次实际抓包时FIN几乎总是和ACK一起出现。如果你在抓包结束后立刻执行netstat -t还能看到客户端的TIME_WAIT状态出现在那条连接的四元组上。这个状态从开始到消失大约要60秒正好对应2MSL的时间窗。5.4 抓包中常见的三类异常特征抓包的主要价值在于排障这里分享三类我线上看得最多的异常特征。第一类同一seq的SYN反复出现且间隔越来越长。这说明第一个SYN发出去后石沉大海客户端按指数退避在重传大概率是网络丢包或者是中间设备悄悄丢弃了SYN。第二类收到RST。RST表示“我不想继续了直接重置”。出现RST时没有重传、没有协商连接被立刻打断。常见原因包括访问的端口没人监听、防火墙主动拒绝、对端应用层异常强行关闭。线上如果大量出现RST需要重点排查是不是有探测流量或者超时踢连接的安全策略。第三类FIN_WAIT_1或CLOSE_WAIT持续堆积。前者需要抓包看 FIN_WAIT_1 的对端是否回ACK如果没回多半是丢包后者则大多数时候是应用层代码问题。抓包看到的是现象但定位时要分清“网络层异常”和“应用层不关闭”两条线。6. 面试拿高分的回答框架我筛选候选人时真正看重的东西6.1 背状态机的答案和讲原理的答案差在哪做个对比低分答案大概长这样“客户端发送SYN进入SYN_SENT服务端收到后发SYNACK进入SYN_RCVD客户端收到后发ACK进入ESTABLISHED。”信息没错但没有说服力。高分答案会长这样“第一次握手客户端宣告我要连序列号是x第二次握手服务端既确认收到又宣告自己的序列号y第三次握手客户端再确认收到y。整个过程只有一个目标就是让双方都确认‘你能收、我能发’这个双向能力。所以必须有三次两次不行因为服务端无法确认自己的宣告是否被客户端收到四次又太多因为第三轮已经完成信息闭环。”后一种回答即使面试官当时不在状态也会不由自主地点点头。它不是在复述过程而是在解释设计意图。6.2 我建议的四层回答框架面对这个问题时我会建议候选人用“一次交互、双向确认、资源释放、异常容错”四层来组织表达。第一层一次交互说清楚三次握手是建立双向通道TCP是全双工的连接代表两个方向的数据通路每条通路都要单独确认。第二层双向确认推导为什么是三次分别阐述第一次握手确认了客户端的发送、服务端的接收第二次握手确认了服务端的发送、客户端的接收同时服务端收到客户端ISN第三次握手让服务端确认客户端收到了自己的SYNACK至此双向闭环。第三层资源释放讲清四次挥手发送方向关一个、确认一个接收方向同理。服务端收到FIN后可能还有数据继续传所以FIN和ACK不一定能合并这是挥手比握手多的根本原因。第四层异常容错主动提到TIME_WAIT最后一个ACK要保证送达还要保证旧报文不会串入新连接所以主动方必须等2MSL。把这一套讲下来大约两分钟。面试官在这两分钟里听到的不只是答案而是你思考网络协议的完整方式。6.3 把ISN、状态机、异常场景串起来讲如果临场被追问细节再往里面加料。比如面试官问“seq为什么是大随机数”你可以立刻接上它既要为字节流排序提供基准又要避免新旧连接报文混淆所以内核用随机化算法生成ISN。问你“第三次握手丢包了什么表现”你可以答服务端一直处于SYN_RCVD会重发SYNACK客户端此时已经ESTABLISHED如果后续它先发数据数据到了服务端反而会让服务端顺势确认连接。这个背靠背的场景推演比单纯说“会重传”要立体得多。讲完这些你已经不是“背题”而是“在讨论一个真实运行的系统”。面试氛围会从考试变成探讨这恰恰是我最希望看到的状态。6.4 一些细节别在这些小问题上栽跟头最后提醒几个容易被忽略的小细节。第一主动关闭方不一定是客户端。任何一端只要需要断开连接都可以主动发FIN。服务端主动断开的情况也很常见比如HTTP服务超时踢掉闲置连接。面试时如果脱口而出“客户端先发FIN”会被看作理解不完整。第二FIN包通常带ACK。有人说挥手的第一步就是“FIN”但抓包工具显示的大概率是FINACK别为这个细节和面试官硬杠。第三挥手不能叫“四次握手”。我听过不少候选人说“关闭连接也是四次握手”每次听到都忍不住皱眉。握手和挥手是两个方向完全不同的机制一个在建立双向确认一个在拆除双向通道用词要准确。第四CLOSED状态应该放在整个状态机的最外围而不是某个节点上。很多人在白板上画状态迁移图时CLOSED位置画错印象分会掉一大截。这些年面试下来我最深的感受是真正的能力不在于记住多少名词而在于能不能把每个设计选择背后的理由讲清楚。TCP三次握手与四次挥手这道经典题正是检验这种能力最好的试金石。它看起来是最基础的知识但能把基础讲出层次的人处理线上复杂问题的时候通常也不会差。把这篇里的逻辑理顺再自己抓一次包验证一遍这顿饭就吃透了。