新集群→直接 KRaft（用附件 1 脚本）老集群→升级到 3.5+ → 按附件 2 迁移永远不要在 Kafka 3.5+ 新集群中引入 ZooKeeper。

/ 这是"保险"方案，确保消息不丢失try {= null) {// 发送失败，写入死信队列log.error("发送失败，写入死信队列", exception);// 超时，也写入死信队列log.error("发送超时，写入死信队列", e);log.error("发送异常", e);// 死信队列实现（可以用另一个 Kafka Topic）DLQ_TOPIC,│ acks 配置选择决策树 ││

│ Consumer 设计"三不要"原则 ││ ││ 1️⃣ 不要在 poll() 和 commit() 之间做耗时操作 ││ 耗时操作 → 放到独立线程池 ││ ││ 2️⃣ 不要依赖默认配置 ││ 默认配置 → 根据业务特点调整 ││ ││ 3️⃣ 不要忽略监控告警 ││ 第一次告警 → 就要重视，不要等故障发生 ││ │。

下次当你写下 volatile 时，请想象一下：你正在按下核按钮，命令所有 CPU 核心停止手中的活，立刻通过数据总线大声广播，并确保所有指令按严格的顺序执行。这就是轻量级同步背后的重型硬件支撑！

ThreadLocal 是好东西，但它不负责打扫卫生。打扫战场，是你作为开发者的责任，主动 remove 是唯一可靠的方案！

JDK 8 用户：如果是新系统，尽量升级到 JDK 17/21。如果必须留在 JDK 8，大堆请用 G1 (需手动开启)，小堆可用 ParallelGC。慎用 CMS。JDK 17/21 用户无脑选 ZGC(特别是 JDK 21 的分代 ZGC)。它已经解决了吞吐量的短板，是目前的最优解。核心心法GC 调优的本质是减少对象分配，而不是调整 GC 参数。最好的 GC 是没有 GC。通过对象池、复用、

“不要试图用战术上的勤奋（手写复杂的锁逻辑），掩盖战略上的懒惰（直接上成熟框架Redisson/Curator）。”“分布式锁不是银弹。它解决了并发冲突，但引入了网络依赖和性能损耗。能不用则不用，能用数据库乐观锁 (UPDATE table SET stock = stock - 1 WHERE id = ? AND stock > 0) 解决的，就别上分布式锁。”“没有最好的锁，只有最适合业务场

“如果你在为钱打交道，请忘掉 Redis 的速度，拥抱 ZooKeeper 的稳重。在一致性面前，性能是可以妥协的，但数据的准确性是底线。”"ZK 锁的本质不是‘抢’，而是‘排队’。它用短暂的等待，换取了绝对的秩序。在分布式系统的混乱中，秩序是最昂贵的奢侈品。”“不要试图用 ZK 抗高并发。ZK 是用来保命的，不是用来冲刺的。让它做最后的守门员，而不是冲锋的前锋。”

“三级缓存是 Spring 设计中‘空间换时间’与‘延迟初始化’思想的巅峰之作。它证明了：即使是最复杂的死结（循环依赖 + AOP），也可以通过引入一个中间层（工厂模式）来化解。不要试图在开始时解决所有问题，有时候，‘推迟决策’才是最高明的智慧。”所以面对死结（循环依赖），不要硬碰硬（立即实例化），也不要逃避（报错），而是引入一个‘缓冲层’（工厂），将‘即时决策’转化为‘按需决策’。

别写 final：除非你真的不想让它被代理（比如工具类）。别在构造函数里玩花样：那是代理的盲区。拥抱 CGLIB：在现代 Spring 应用中，它的性能损耗几乎可以忽略，带来的灵活性却是巨大的。关注 Native：如果你要上 GraalVM，请提前研究 Spring AOT 如何处理 CGLIB 生成的类。