最近各家中大厂在开启春招的同时，也在沟通年终系数。
今天鸭鸭看到，美团前几天也开奖了。
今年美团的年终奖是 3.5 个月，不过还得根据你的个人表现，乘一个最终系数。而系数浮动需要看你前一年的工作表现，从目前爆料来看，今年系数大抵是这样的：
-
超出预期：系数大于 1，还有可能调薪或增发股票；
-
符合预期：系数等于 1；
-
不及预期：系数小于 1，且可能为 0。
目前爆料的同学，年终奖到手各不相同：
有到手 4.8 个月，感觉重在参与的。
也有到手 3 个月，心情五味杂陈的：
今年 3.5 个月作为基数，从数字上看，确实不低，但加上系数，就是几家欢喜几家愁了。
你绩效好，系数大于 1，那就香得很；绩效一般，系数等于 1，也还凑合；但要是绩效不佳，系数小于 1，甚至直接归零……
那这一年忙到头，一看奖金，真百味杂陈了。
去年美团和京东都在打外卖大战。
结果今年美团和京东的年终奖一对比，京东今年直接干到 20-25 薪，采销部门平均 23 薪，A+ 绩效甚至能到 8 倍月薪。而美团今年年终奖只有 3.5 个月，基数还得再乘系数。
基数是和绩效强绑定的。而绩效这个东西吧，有时候真不是你能完全掌控的：
部门业绩怎么样，领导怎么看你，甚至公司整体情况好不好，都可能影响你的最终评级。
这种不确定性，才是最让人头大的。
鸭鸭就看到有员工吐槽：
说到这里，突然想到，美团今年的春招好像也开始了。
网申时间从 3 月 2 日开始，一直持续到 5 月 31 日。
岗位类型挺丰富的，今年校招的同学也可以去看看。
美团 2026 春招：mp.weixin.qq.com/s/_ODcZ74Mp…
话说回来，年终奖这东西，该发多少，自己也没办法左右，与其纠结系数，不如想想，年终奖到账，你会拿这笔钱做点什么呢？给自己买个礼物奖励一下自己过去一年的工作？还是准备一场旅行？
欢迎来评论区说说。
……
今天分享一篇美团面经。
篇幅有限，完整答案可以进入面试鸭 - 2026程序员面试题库大全 | 10000+Java/前端/Python面试题免费刷进行查阅。
TCP 如何建立连接？
TCP 三次握手就是客户端和服务器通过发送和确认三个包，保证双方的收发能力正常，且同步初始化序列号，并建立可靠连接的过程。
1）第一次握手（客户端 -> 服务端）
客户端发送一个 SYN 报文（SYN=1），并携带一个随机生成的初始化序列号（seq=x）。
此时客户端处于 SYN_SENT（同步已发送）状态。
2）第二次握手（服务端 -> 客户端）
服务端收到 SYN 后，回发一个 SYN+ACK 报文（SYN=1, ACK=1）。确认号是客户端的序列号 + 1（ack=x+1），同时自己也生成一个初始化序列号（seq=y）。
此时服务端处于 SYN_RCVD（同步收到）状态。
3）第三次握手（客户端 -> 服务端）
客户端收到 SYN+ACK 后，发送一个 ACK 报文（ACK=1）。确认号是服务端的序列号 + 1（ack=y+1）。
此时客户端进入 ESTABLISHED（已建立连接）状态。服务端收到 ACK 后，也进入 ESTABLISHED 状态，连接正式建立。
三次握手可以减少么？减少一次会怎么样？最终导致的结果是什么？
使用三次握手的首要原因是：为了阻止历史的重复连接初始化导致的混乱。
假设只有两次握手
- 客户端发送了一个 SYN 请求，因为网络拥堵滞留了。
- 客户端超时，重发了新的 SYN 。
- 但是后来的那个滞留的旧 SYN 反而先到达了服务端。
- 服务端无法识别当前的请求是旧的请求还是新的请求，误以为是新的连接请求，于是回复 SYN+ACK 并直接进入 ESTABLISHED 状态
- 紧接着服务端给客户端发送数据
- 客户端接收后发现 ack 不对，于是发送 RST 终止连接。
- 新的 SYN 终于到达服务端，服务端依旧无法识别当前的请求是旧的请求还是新的请求，以为是新的连接请求，于是回复 SYN+ACK 并直接进入 ESTABLISHED 状态
- 终于建连成功
两次握手无法避免历史连接的建立，导致建立了一个无效的连接，还可能无效发送数据，白白浪费了资源。
因此为了避免这种情况发生，两次通信是不够的。客户端需要知晓服务端到底接受了哪个连接
- 如果接受的是老连接，那么客户端需要告知服务端，这个连接不对！也就是 RST 通知。
- 如果接受的是新连接，那么客户端就返回 ACK 告诉服务端 OK！这就使得一次握手至少需要 3 次。
因此只有三次握手，才能让客户端有“开口解释”的机会，确认服务端接受的连接是否正确，从而阻止历史连接的错误建立。
篇幅有限，完整答案可以登陆面试鸭（mianshiya.com）查看。
