第一次真正感受到“技术判断”这四个字，不是在写完代码的时候，而是在一次方案评审前。需求看起来并不复杂，业务要上线一个新能力，时间不算宽裕，但链路很长，涉及多个模块联动。导师把文档丢过来，只说了一句：先别急着写，先把可能出问题的地方找出来。 我最开始也和很多实习生一样，下意识会先看接口、看表结构、看怎么把功能做出来。但越往下梳理，越发现这不是一个“把需求实现”就结束的任务。高并发场景下，任何一个看起来正常的调用路径，都可能在流量起来之后变成瓶颈；任何一个默认重试、超时设置、依赖堆叠，都可能把局部问题放大成全链路抖动。 于是我先没动代码，反而花时间把调用链、异常路径和兜底逻辑一条条画清楚。哪些请求...

一开始还有一些小厂中厂找我，现在啥都没有了

本2硕9，力扣是没刷完的，八股是没背完的，准备先投中小厂练练手，逼自己先面试找找感觉。大厂到底什么时候才配投啊，看了面经能掰扯的最多才一半

各种拷打项目，结合项目来问八股 答得不太好的   SACK 在标准 TCP（如 TCP Tahoe 或 Reno）中，确认号（ACK Number）仅表示接收端已成功接收的连续字节流边界。一旦中间某个分节（Segment）丢失，即使后续更高序号的分节已到达并存入接收缓冲区，接收端也只能发送该缺失分节起始序号的 ACK。  累积确认位：依然保留，用于指示当前已按序收到的最后一个字节。 SACK 选项字段：在 TCP 报文头的 Options 字段中，新增了 SACK 块。每个块由一对 左边界 (Left Edge) 和 右边界 (Right Edge) 组成，精确描述了接收缓冲区内已收到的非连续...