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

😭这是给挂了吗，都一周了还显示这个。。。。

1、业务表现服务不可用，转圈圈2、上日志Redisson + Netty 堆内存溢出（OOM）问题完整解决方案你遇到的核心错误是：Java 堆内存不足，且溢出发生在 Redisson 编码发送 Redis 命令 的阶段（Netty 编码器），这是典型的大对象 / 大批量命令 / 内存配置不足导致的 OOM。先给你最关键的结论：这个 OOM 不是普通的内存泄漏，90% 是因为你一次性往 Redis 发送了超大数据 / 批量命令，或者 JVM 堆内存配置太小，Redisson 编码时直接撑爆了堆。一、快速定位根因（3 个最常见原因）结合你的日志（CommandEncoder/CommandBatc...