那是一个周四下午，距离大促还有不到两天。 我正在按照清单做最后的上线检查，没什么特别的。监控正常，流量平稳，接口响应也没有问题。照理说，我应该打个对勾，然后准时下班。 但那条日志让我停了下来。 不是报错，也没有触发告警。只是一条看起来有点奇怪的日志：某个下游服务在低频情况下返回了一个不太对劲的状态码，没有被任何监控规则捕获，却在日志里安静地躺着。 我盯着它看了很久。 说实话，我不确定这算不算问题。我在这里实习才一个多月，对这套系统的了解还不够深。也许这是正常的降级逻辑，也许是某个不影响主流程的边缘情况。我甚至想过，要不先记下来，等大促过了再说。 但我还是在群里发了一条消息，@了我的导师：&qu...

offer审批等了三天今天终于下来了，一个不好的消息就是暑期变日常了，但是hr说还是可以转正，感觉转正机会还是很渺茫的听说也是晚上十点十一点下班

周五投了 tx，部门选的任意，今天来约面电话了，结果是 wxg，还是微信支付？？纯血 C++来捞我一个纯 java 的简历？？问我接不接受转语言，我说考虑转 go 但是从来没考虑转 C++，然后还是说让我面试尝试一下？？？说面试不会考语言。面试官是个女生，口音听着像台湾那边的现在看网上 WXG 的面经已经吓哭了，不会上来就让我写四道 hard 吧，hot100 选手已投降🏳️

1. 你的项目中使用了消息队列（MQ），如何保证消息的可靠性投递（不丢失）？回答：保证可靠性需要从三个阶段入手： 生产者阶段：开启确认机制（如 RabbitMQ 的 Confirm 模式或 RocketMQ 的同步发送）。发送失败时进行重试，或者记录日志入库。MQ 节点阶段：开启持久化（交换机、队列、消息全部持久化到磁盘）。如果是集群环境，使用镜像队列或多副本同步，确保 Leader 宕机后数据不丢。消费者阶段：关闭自动 ACK，改为手动 ACK。只有在业务逻辑处理成功后才返回确认，防止消息在处理中途由于异常丢失。2. 谈谈 Netty 的高性能架构，为什么它比传统的 Tomcat 连接器更快...