首页
/
行业洞察
/
正文
INDUSTRY INSIGHT · 深度
TCP三次握手四次挥手:连接状态同步与期末大题高分攻略
📅 2026/10/11 17:17:12
✍️ 爱科研究院
👁 阅读 3,247
刚开始复习计算机网络那阵子三次握手和四次挥手这两块我背了不少遍可一到期末大题还是写不全。不是因为记不住四个步骤的名字而是总搞不清这个包为什么要长这样、那个状态为什么要存在出题人把方向一变就懵了。后来我把底层的状态同步逻辑彻底捋了一遍才明白握手和挥手本质上就是同一套“建连状态同步”和“连接回收确认”的规则跟着规则走任何变体题其实都在套路之内。这篇文章结合我自己复习和批改模拟卷的经验把三次握手、四次挥手从头到尾掰开揉碎专门讲期末大题的踩分点、画图方式、确认号计算和常见陷阱适合正在冲刺阶段、想拿高分的同学直接使用。1. 为什么三次握手总是一问一个准——考点定位与命题规律分析1.1 三次握手和四次挥手在期末大题里的高频考法计算机网络期末卷子里绕不开的几座大山TCP 三次握手、四次挥手、滑动窗口、拥塞控制。真要论“出题密度”握手和挥手几乎每一届都会出现而且通常就放在大题位置。常见形式有这么几种第一类是流程描述题直接让你画出三次握手和四次挥手过程图标注每个报文段的 SYN、ACK、FIN 标志位以及 seq、ack 序号变化。这类题看着简单实则是重灾区因为很多人画得出来但标注不全。第二类是状态判断题给你某一个时间点问你此时双方处于什么状态。比如服务器处于 SYN_RCVD它收到了什么、发回了什么又比如客户端处于 FIN_WAIT_2它还能不能接收数据。这类题考的是状态机的迁移逻辑死记硬背容易漏项。第三类是原因分析题问你为什么需要第三次握手、为什么挥手要四次、为什么 TIME_WAIT 要等 2MSL。这类题是拉分的关键只会背流程的同学到这里就写不出踩分点了。第四类是异常场景推理题比如第二次握手报文丢失会怎样、客户端收到一个很久之前的旧 SYN 应如何处理、主动关闭方迟迟收不到 FIN 会触发什么机制。这类题综合性强喜欢放在大题最后一小问。大题之所以偏爱这部分是因为它有很强的“可画性”和“可推理性”。画图题能考你对协议流程的记忆推理题能考你对设计原因的理解。阅卷时两极分化很严重框架图完整的给高分缺一个 ACK 或者状态名写错的直接扣掉一大半。所以复习时必须按照“能默写、能推导、能变通”三个层次去准备而不是只会背。1.2 握手的本质一条状态同步的规则不少同学把三次握手背成“客户端发 SYN服务器回 SYNACK客户端回 ACK”这没错但它只是一个表象。考试想不丢分你要理解另一层握手的目的是让双方在一条“虚拟通信管道”上确认彼此的发送能力和接收能力都正常并且把初始序号对齐。TCP 是面向连接的可靠传输协议。面向连接这四个字听着抽象落到报文字段层面其实要解决三个问题其一客户端怎么知道自己的发送正常、服务器的接收正常其二服务器怎么知道自己的发送正常、客户端的接收正常其三双方的序号从哪个数开始算这三个问题的答案本质上就是握手过程本身。第一次握手确认了服务器的接收能力第二次握手同时确认了客户端的接收能力和服务器的发送能力第三次握手则让服务器确认客户端的接收能力同时完成双方初始序号的同步。把这个逻辑想通了后续变体题基本都能顺藤摸瓜。另外还有一个备考角度容易被忽略握手和挥手不是两类知识而是同一套机制的两面。建立连接是双向确认发送和接收能力关闭连接是双向确认“我不再发送了”。你如果把状态迁移图合并成一张表复习效率会高很多。2. 三次握手全程拆解从SYN到ACK的每一步2.1 第一次握手客户端怎么发出那个SYN报文三次握手的发起方通常是客户端也就是主动请求建立连接的一方。第一次握手时客户端构建一个 TCP 报文段把 SYN 标志位置为 1随机生成一个初始序号记为 seq x然后发送给服务器。这个报文不携带应用层数据它只有一个目的告诉服务器我想建立连接我的初始序号是 x。这里有个很容易被忽略的考点客户端发出 SYN 后进入 SYN_SENT 状态。在 Linux 的 netstat 输出里你能看到这条连接的 TCP 状态是 SYN_SENT。如果服务器一直不回应客户端会触发超时重传机制重传次数和间隔由系统配置决定这也是后面综合题经常借题发挥的“如果 SYN 丢了会怎么样”。我第一次实际看抓包时特别疑惑为什么初始序号不用固定的 1而是要随机生成。后来查了资料才明白这是出于安全性考虑。如果序号固定攻击者有机会猜测或者伪造后续的报文序列号从而干扰甚至劫持连接。随机化 ISN 并不能彻底杜绝攻击但至少让猜测难度大幅上升。考试如果问到“ISN 为什么随机”答出“安全考虑避免序号猜测攻击”就已经踩到得分点了。2.2 第二次握手服务器回SYNACK的细节服务器收到 SYN 后如果同意建立连接会回复一个报文。这个报文很特殊SYN 标志位置 1ACK 标志位也置 1。它的含义是我收到了你的 SYN确认你的初始序号 x 已经接收同时我也发起我这一侧的 SYN我的初始序号是 y。注意第二次握手的确认号必须是 x1而不是 x。因为 TCP 的确认号表示“期望收到对方的下一个字节序号”也就是说“x1 之前的字节我都收到了下一个请给我 x1”。这个规则在你后续计算任何确认号时都适用一定不能记反。服务器的状态在发出 SYNACK 之后进入 SYN_RCVD。SYN_RCVD 说明服务器已经收到 SYN发回了 SYNACK但还在等客户端的最终 ACK。在这个状态下连接还没有真正建立双方也还不能开始传数据。期末考试如果请求你画出这个状态点一定要把 SYN_RCVD 写在服务器一侧而不是客户端一侧。2.3 第三次握手客户端发出那个确认ACK客户端收到服务器的 SYNACK 后先检查确认号是不是 x1。如果是说明服务器已经正确收到了自己的 SYN同时客户端也从中读到了服务器的初始序号 y。于是客户端发送一个 ACK 报文确认号是 y1ACK 标志位置 1。这个报文可以携带数据也可以不携带看具体实现和时机。客户端发出 ACK 后进入 ESTABLISHED 状态服务器收到 ACK 后也从 SYN_RCVD 进入 ESTABLISHED。到这一步双方才真正可以传输数据。这里想强调一个细节第三次握手的 ACK 到底有没有必要答案是一定有。去掉第三次握手会引发什么问题就是下一节要讲的核心考点。期末大题经常把“为什么三次而不是两次”和“第三次握手丢了怎么办”连在一起考前者问设计原理后者问异常机制两个都不能含糊。2.4 序号与确认号的计算规律三步法我批改模拟卷时发现学生大多在序号和确认号上算错。这里给一个非常实用的三步法第一步先把每个报文段列出来标出方向、标志位、seq 序号、ack 确认号。第二步记住两条铁律seq 是本报文段数据部分的第一个字节序号SYN 和 FIN 标志位都占一个序号位即使不携带数据。第三步画一个时序表格每写一个 ack先问自己“这个 ack 是不是期望对方下一个字节的序号”。如果是就算对了。举一个典型例子客户端发 SYNseq100数据长度 0。服务器回 SYNACKseq200ack101。因为期望客户端下一个字节是 101SYN 本身占了一个序号位。客户端收到后回 ACKseq101ack201。这时客户端后续正式发送数据时它的第一个数据字节序号就是 101 了。几乎每一届期末卷都会出现一个类似变体比如把 seq 换成 500、1000或者加入一段数据长度。原理不变但算错的人非常多。原因就是对“SYN 占序号”没有概念。只要记住这个点确认号计算题就是送分题。3. 为什么要握三次手而不是两次——核心原因考点3.1 两次握手的致命缺陷旧报文“复活”这个考点是握手类大题的满分关键。如果只握两次手会发生什么假设网络中存在一个迟到的旧 SYN 报文它来自上一次已经关闭的连接。由于网络延迟它绕过了正常时序直到这次连接结束之后才到达服务器。服务器不知道这是一个过期的报文以为客户端正在发起新连接于是回复 SYNACK进入 SYN_RCVD连接被“半建立”起来。如果没有第三次握手服务器会认为连接已经建立开始分配资源、等待数据。而客户端根本没有发送新连接请求它不会回应任何数据。服务器只能白白等待占着资源不释放。更麻烦的情况是如果这个旧报文碰巧被服务器当成了新连接而客户端此时又确实想发起新连接两个连接相互交错数据就会错乱。三次握手的作用之一就是让客户端有机会在第三步告诉服务器这个连接请求是废弃的我不认。通过这样的拦截无效连接被挡在门外服务器的资源不会被白白消耗。3.2 三次握手如何拦住历史连接RST复位的过程三次握手为什么能够拦截历史连接关键在于客户端收到服务器的 SYNACK 后会根据确认号来判断这条连接是否有效。如果客户端当前期望服务器确认的序号是 x2而服务器回的确认号却是 x11对应某个旧 SYN客户端立刻就能识别出这是一个历史连接。它会向服务器发送一个 RST 报文请求复位。服务器收到 RST 后进入 CLOSED 状态不再为这个连接分配资源。这个过程在 TCP 标准中叫“历史报文段检测”。期末大题如果问“为什么不能只握两次手”答案能写出“防止旧连接请求导致服务器资源被白占防止历史报文干扰新连接”这两层意思得分率会高很多。千万不能只答一句“因为需要双方确认发送和接收能力”那个答案虽然方向不错但太宽泛大题阅卷是按踩分点给分的写不到位等于没写。3.3 握手异常场景的速查丢包和超时重传除了“为什么三次”还有一类高频配合题是“超时与重传”。比如第二次握手丢失了客户端长时间收不到 SYNACK会怎么做答案是客户端会认为自己发的 SYN 丢了触发超时重传重新发送 SYN。服务器这边呢它其实还没有建立任何有效状态因为第二次握手丢了。服务器会停留在 SYN_RCVD直到超时或者收到新的 SYN。如果收到客户端重复发送的 SYN服务器会重新响应。这类题目一般不会让你精确计算重传时间更多是出现在综合题的最后一问考你对“哪个报文丢失会导致什么状态”的判断。我把常见情况整理成一张表建议直接抄进笔记丢失的报文客户端状态服务器状态后续行为第一个 SYNSYN_SENT等待响应无感知客户端超时重传 SYN服务器 SYNACKSYN_SENT等待响应SYN_RCVD等待确认客户端重发 SYN 或服务器超时重发 SYNACK客户端 ACKESTABLISHEDSYN_RCVD等待最终确认服务器超时重发 SYNACK直到连接回收这张表在笔记里自己动手画一遍比单纯背十遍都管用。大题里只要出现“某报文丢失双方处于什么状态”的小问基本都能直接往上套。4. 四次挥手全流程拆解从FIN到ACK的告别四次挥手的“四次”并不是四个步骤都是同一性质的报文。它的本质是“两次独立的单向关闭”叠加在一起。这个点不理解就很难解释清楚为什么挥手要四次。TCP 连接是全双工的一条连接实际上包含客户端到服务器、服务器到客户端两个方向。每个方向都要单独关闭而每个方向的关闭都对应一次 FIN 和一次 ACK所以理想情况下是四次报文交换。4.1 第一次挥手主动方发出FIN通常主动关闭方是客户端但注意考试题里也可能反过来。只要是主动关闭的那一方流程和状态就是一样的。主动方发送一个 FIN 报文seq 是当前最后一个已发送数据字节序号加 1表示“我这边数据已经全部发完我要关闭我这个方向的数据发送”。这个 FIN 本身也会消耗一个序号。发出 FIN 后主动方状态从 ESTABLISHED 转向 FIN_WAIT_1。很多同学只记得 FIN 表示关闭却忘记它同样占用序号。计算确认号时一旦漏掉 FIN 的占位整个答案就会出现系统性偏差。把 FIN 和 SYN 一起记凡是控制连接建立或关闭的标志位都要消耗序号。4.2 第二次挥手被动方回复ACK并进入CLOSE_WAIT被动方收到 FIN 后回复一个 ACK确认号是 FIN 的 seq 加 1。被动方把状态从 ESTABLISHED 改为 CLOSE_WAIT。此时被动方仍然可以向主动方发送数据因为被动方这一侧的发送方向还没关闭。主动方收到 ACK 后从 FIN_WAIT_1 进入 FIN_WAIT_2。CLOSE_WAIT 这个状态考频极高。它代表“对方关闭了它的发送方向我这边应用层还需要处理剩余逻辑”。如果一个线上服务器出现大量 CLOSE_WAIT 连接基本可以断定是程序没有正确关闭 socket。这个知识点不仅期末常考将来做运维排查也一定用得上建议连原因一起记。4.3 第三次挥手被动方处理完数据再发FIN被动方应用层处理完剩余数据后发送 FIN表示“我这边也发完了可以彻底关闭”。被动方状态从 CLOSE_WAIT 转为 LAST_ACK。LAST_ACK 的意思是“我已经发出 FIN正在等待对方的最后一个 ACK”。这里特别要解释一点为什么第二次和第三次不能合并成一个 FINACK因为被动方收到 FIN 时可能还有数据没有发送完毕。它不能立刻关闭自己的发送方向必须先回一个 ACK告诉对方“我知道了但请等我一下”。等剩余数据发完被动方再单独发 FIN。这就是挥手需要四次的核心原因。考试作答时这一句一定要写出来。4.4 第四次挥手主动方回复ACK并进入TIME_WAIT主动方收到 FIN 后回复 ACK确认号是 FIN 的 seq 加 1。主动方进入 TIME_WAIT等待 2MSL 后正式关闭。被动方收到 ACK 后进入 CLOSED 状态彻底关闭连接。这里有一个非常经典的问题主动方能不能不进入 TIME_WAIT直接关闭理论上有隐患。因为最后这个 ACK 可能丢失被动方在 LAST_ACK 状态会超时重发 FIN。如果主动方直接关闭收到重发的 FIN 时已经没有这条连接的任何记录无法重新回复 ACK。被动方会一直等不到 ACK无法确认关闭资源一直无法释放。TIME_WAIT 让主动方保留足够长的时间去处理这类重发的 FIN。4.5 TIME_WAIT的两大作用与2MSL的由来期末大题的判断题、简答题、填空题都会考 TIME_WAIT至少记住两个作用第一个作用保证最后一个 ACK 丢失时能够重发。如果 ACK 丢了被动方重发 FIN主动方在 TIME_WAIT 状态下可以收到并重新发送 ACK保证被动方正常关闭。第二个作用让旧连接的报文在网络中彻底消失避免“迟到报文”污染后续新连接。TCP 报文在网络上有一个最长生存时间 MSL等待 2MSL 能确保旧连接的所有报文段全部过期失效。如果 TIME_WAIT 时间太短一个旧的 FIN 或数据段混入新连接会造成数据错乱。还有两个总是被连在一起问的问题TIME_WAIT 持续多久为什么是 2MSL答案是一个 MSL 用于等待自己发的 ACK 在网络中消失另一个 MSL 用于等待对方可能重发的 FIN 到达。如果对方重发 FIN这个 FIN 在路上最多需要 1 个 MSL加上我方 ACK 本身的 1 个 MSL2MSL 是一个合理的安全窗口。5. 大题答题模板与得分点拆解大题想拿满分不光是会还得按踩分点去答。阅卷老师通常不会细读你写的每一句话而是快速扫关键词和状态迁移。所以答题结构比文采重要得多。5.1 大题作答框架画图加标注加解释三件套如果期末大题要求说明三次握手和四次挥手的过程我建议按三步作答。第一步是画图。画一条竖线当时间轴左侧写客户端右侧写服务器。客户端发 SYN服务器回 SYNACK客户端回 ACK然后进入数据传输阶段。之后再画四次挥手依次是 FIN、ACK、FIN、ACK。箭头方向要清晰每个报文段旁边标注标志位、seq、ack双方侧边写上状态迁移。第二步是写过程描述。分点写每一点对应一个报文。第一次握手客户端发 SYN携带初始序号 x进入 SYN_SENT。第二次握手服务器回 SYNACK携带初始序号 y确认号 x1进入 SYN_RCVD。第三次握手客户端回 ACK确认号 y1双方进入 ESTABLISHED。挥手流程按同样格式展开。第三步是写设计原因。如果题目要求解释补上“为什么要三次”和“为什么 TIME_WAIT”这两段踩分点基本都在这里。注意画图时不要只画箭头不写状态。状态迁移是阅卷老师重点关注内容。SYN_SENT、SYN_RCVD、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、CLOSE_WAIT、LAST_ACK、TIME_WAIT、CLOSED 这九个状态下笔之前先在草稿纸上默念一遍。画错一个状态可能丢失整题的连续性分数。5.2 阅卷视角下最容易被扣分的细节盘点我批改模拟卷时发现学生在下面这些细节上反复丢分ACK 标志位和 ack 确认号混用。ACK 是标志位ack 是确认号字段两个东西。答题时不要写“ACKx1”要写“ACK 标志位置 1确认号 ackx1”。seq 和 ack 搞反。seq 是自己的序号ack 是期望对方下一个字节的序号。第二个报文同时有 SYN 和 ACK 时它既携带自己的序号 y又携带确认号 x1两套数字不能混。FIN 消耗序号。算四次挥手确认号时很多人漏掉 FIN 占位。比如 FIN 的 seq900那么 ACK 的确认号应该是 901。SYN_SENT 和 SYN_RCVD 方向搞混。客户端发出 SYN 后是 SYN_SENT服务器收到 SYN 发出 SYNACK 后是 SYN_RCVD。这个在状态图上极其显眼写反就是整题崩盘。挥手顺序记反。记住主动方先发 FIN被动方第二次回 ACK之后被动方再发 FIN主动方最后回 ACK。第二次和第三次不能调换。这些细节都不是难题纯粹考细心。做题时可以在答案右侧列一个状态对照栏每写一个状态就检查一次是否与对应报文匹配。5.3 一道典型综合大题的完整作答演示给一个期末考试风格的题目做完整示例。题目某客户端与服务器建立 TCP 连接客户端初始序号为 1000服务器初始序号为 5000。请描述三次握手过程标注各报文段的 seq、ack 值随后客户端主动关闭连接描述四次挥手过程并说明 TIME_WAIT 状态的作用。答题示范三次握手过程客户端发送 SYN 报文seq1000ACK 标志位置 0进入 SYN_SENT。服务器收到后回复 SYNACK 报文seq5000确认号 ack1001ACK 标志位置 1进入 SYN_RCVD。ack1001 表示已收到序号 1000 的 SYN期望客户端下一个字节序号为 1001。客户端发送 ACK 报文seq1001确认号 ack5001ACK 标志位置 1进入 ESTABLISHED。服务器收到后也进入 ESTABLISHED。四次挥手过程以客户端主动关闭为例客户端发送 FIN 报文seq 为最后一个数据字节序号加 1假定为 8000进入 FIN_WAIT_1。服务器回复 ACK确认号 ack8001进入 CLOSE_WAIT。客户端收到 ACK 后进入 FIN_WAIT_2。服务器发送 FINseq9000进入 LAST_ACK。客户端回复 ACK确认号 ack9001进入 TIME_WAIT。服务器收到后进入 CLOSED。客户端等待 2MSL 后进入 CLOSED。TIME_WAIT 的两个作用保证最后一个 ACK 丢失时能够重新回复等待旧报文在网络中消失防止迟到报文污染后续新连接。这道题如果按这个结构答二十多分的大题基本稳了。关键是把状态和确认号数值写得清清楚楚让阅卷老师不需要自己推算就能看到结论。6. 常见的理解误区与考前速记技巧考前最怕的不是背不下来而是背下来但不理解一出变体题就答歪。这里把高频误区集中梳理一遍。6.1 六个最常见的错误理解误区一认为第二次握手的确认号是 y1。很多同学看到服务器回 SYNACK就把 y1 当成确认号。实际上服务器发 SYN 时 seq 是 yack 是 x1。y1 是客户端在第三次握手时回的确认号。这个错误说明你没把两个方向的序号信息分开。误区二认为四次挥手一定由客户端发起。实际上任何一方都可以主动关闭。如果题目没有明确你可以假设客户端主动关闭但一定要在描述里写清楚“以客户端主动关闭为例”避免阅卷老师诘问你场景预设不对。误区三把 CLOSE_WAIT 和 LAST_ACK 弄混。CLOSE_WAIT 是被动方收到 FIN 后、还没发 FIN 之前停留的状态本质是等待应用层完成剩余工作。LAST_ACK 是被动方发出 FIN 后、等待对方确认的状态。一个在等应用层一个在等网上 ACK。误区四认为 TIME_WAIT 只属于客户端。准确说TIME_WAIT 属于主动关闭方。如果服务器主动断开连接服务器也会进入 TIME_WAIT。把客户端和 TIME_WAIT 划等号是常见的错误。误区五把挥手四次的原因只归结为“TCP 是全双工的”。这句话作为答案的开头引子是可以的但不能只写这一句。你要写清楚每个方向的关闭都需要 FIN 加 ACK 组合而且被动方在收到 FIN 后可能还有数据要发所以 ACK 与 FIN 不能合并这才造成了四次。误区六认为第三次握手不携带数据就可以省略。第三次握手的作用是通知服务器“客户端已经收到服务器的 SYN”这个通知本身是连接建立的必要条件。哪怕不携带应用数据第三个 ACK 也必须存在。6.2 考前速记口诀与复习优先级如果距离考试只剩一天建议按这个顺序分配精力先默写三次握手和四次挥手的状态迁移图各两遍再背熟“为什么三次”和“为什么 TIME_WAIT”两段原因最后刷十道确认号计算题。记忆口诀可以这样用三次握手你问我答再确认从此可以传数据。四次挥手先说再见对方答应对方再说再见我最后答应等一分半彻底拜拜。口诀只能帮助记忆顺序真正的踩分点还是落在标志位、状态名和确认号上。考试时可以用口诀快速定位步骤但写答案必须用规范术语。我把复习优先级按往年真题的出现频率排个序第一优先是三次握手画图加确认号计算第二优先是四次挥手画图加 TIME_WAIT 分析第三优先是异常场景综合推理。前两个是拉分主力第三个是区分度所在能拿一分是一分。最后分享一个我反复验证有效的备考操作把三次握手和四次挥手按“方向、报文标志位、seq、ack、发送方状态、接收方状态”六列画一张大表填满之后对着空白版自己默写三遍。这张表花不了四十分钟却能把期末大题 90% 的细节踩分点全部覆盖。考前最后一眼看这张表比你翻十页笔记都高效。
📌 标签:
工业官网
设计趋势
AI 建站
SEO
获取完整报告 →
RELATED ARTICLES
推荐阅读
2026/10/11 17:12:12
如何从零构建 AI File Sorter:跨平台源码编译完整指南(含 llama.cpp 多后端运行时)
2026/10/11 17:12:12
三层交换机VLAN配置实战:从SVI到跨VLAN通信排障全解析
2026/10/11 17:12:12
HaleHound-CYD防御模式指南:Jam Detect全频段干扰检测与Blue Team蓝队模式切换
2026/10/11 20:17:27
Flutter与OpenHarmony门禁App实战:桥接、缓存与权限管理
2026/10/11 20:17:27
网页图片保存不了怎么办?5种真正实用的图片下载方法,支持高清原图和批量保存
2026/10/11 20:17:27
基于YOLO的智能追踪云台:从检测到运动控制的闭环实战
2026/10/11 20:17:27
UniClipboard 剪贴板数据存在哪里?安全模型与审计清单完整指南
2026/10/11 20:17:27
H5游戏源码斗地主.zip:从解压到玩法改造的完整实战指南
2026/10/11 20:12:26
响应式实时数据处理:从概念到落地的完整技术链路
2026/10/11 0:00:10
流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南
2026/10/11 0:00:10
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别
2026/10/11 0:00:10
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容
2026/10/11 0:00:10
流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南
2026/10/11 0:00:10
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别
2026/10/11 0:00:10
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容
2026/10/11 19:13:46
我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频
2026/10/10 3:41:54
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证
2026/10/9 11:36:17
2026 大模型集体涨价:用 Python 做企业 Token 成本测算与选型避坑(附配置)