制造系统里有个经典场景：工人手持终端扫一个箱码，点「生产入库」。那天接口卡了二十多秒，工人以为没点上，又点了一次——两次请求都成功返回，库里多了一模一样的两套库存：库存明细、状态表、入库记录、操作流水，四张表整整齐齐各两行。
代码里明明有查重校验（”当前条码已入库，不可重复入库”），为什么两次都没拦住？这篇文章完整复盘根因链：类级注解把整个入库方法包成一个大事务 → 事务内 MVCC 快照读对并发未提交的插入天然失明 → check-then-act 查重形同虚设 → 生产库唯一索引恰好是普通索引，最后一道兜底也不存在。以及修复方案里一个容易被一笔带过的细节：多条码批量提交时，为什么要按条码排序后依次获取锁才不会死锁。最后附上面试视角的问答拆解——这个问题几乎覆盖了 MVCC、锁、事务、隔离级别的全部高频考点。
上一篇《接口限流落地复盘》从工程师视角把”算法之外的一切”拆了个遍：拦截器在哪类应用会静默失效、身份从哪取、响应契约怎么对齐、Redis 挂了怎么办、落库不能成为新故障源。那是一篇”怎么做”的复盘。
这篇换三个座位重讲同一件事：架构师的视角负责问”该不该做、边界画在哪、哪些必须说 No”；产品经理的视角负责问”做了之后谁用、怎么用、能不能运营、价值怎么衡量”；高级工程师的视角负责问”落到代码里，哪些地方写着写着就会悄悄烂掉”。前两者决定方案成立与活下来，第三者决定它经不经得起十年老系统天天被每个请求穿过。
如果只把限流写成一个 RateLimiter 类，它只会躺在公共包里等人调用；只有把它做成”可运营的能力”、并用经得起磨损的工程手艺实现，它才会真正改变系统的可靠性水位。下半场不在代码里，在架构、产品与工程这三重视角里。
前面两篇分别讲了工程师视角的落地复盘和架构师与产品经理把它做成产品的下半场。这一篇换一个角度：把整套实现”拆零件”，逐个讲清楚代码里到底用到了哪些技术、为什么这么用、哪些是踩出来的。不堆概念，全部对应当时项目里的真实实现（@RateLimit 注解、RateLimitInterceptor、RateLimitService、RateLimitRuleCache、RateLimitApiIndexReporter 等）。
最近在一套服务端渲染的制造执行系统（Spring Boot 2.1 + Spring Cloud 老版本微服务，JSP + EasyUI 前端，十几个业务服务）里做了一个统一接口限流组件。起因不是优化诉求，是一次生产事故：疑似客户侧用脚本对系统做批量数据查询，请求洪峰把业务服务直接打死了。复盘时发现这类风险早有伏笔——一条库存流水查询接口带全表聚合，页脚汇总要六秒多，人手连点就能把它拖垮；另一个条码查询接口早被脚本连点过，业务同事在 Service 里手写了一段”十五秒内只许查一次”的私有判断，散落在业务代码里。事故只是把这些既有脆弱点一次性引爆。
做完整个工程回头盘点，一个感受越来越清晰：Redis 固定窗口计数是全部工作里最简单的部分，两个小时就写完了；真正花时间、真正值得复盘的，是算法之外的一切——拦截器在哪类应用里会静默失效、限流键从哪取身份、被拦的响应长什么样、Redis 挂了限流器怎么办、运维怎么不重启调参、前端怎么消化”被限流”这个新的失败模式。
市面上九成的限流文章在对比算法：固定窗口的边界突刺、滑动窗口的内存开销、令牌桶的突发容忍、再补一段 Lua 脚本保证原子性。这些内容对，但它们回答的是”怎么实现一个限流器”，而不是”怎么在一个跑了十年、前后端契约刻在化石里的系统里落地限流”。这篇文章讲后者。
一个平静的下午，测试环境的报表页面突然打不开，接口 500。报错是 Spring 的参数名解析失败——而相关代码（一个所有微服务共享的框架 jar）已经几周没人动过。更玄学的是：同一个 URL 两种异常交替出现；部署着完全相同 jar 的其他服务，同款请求全部 200。
最后定位到的根因与代码无关：一次再普通不过的 Maven 构建，把本地仓库里的 SNAPSHOT 依赖 jar 原地覆写成了新构建，毒化了所有在覆写之前启动的 JVM。这篇文章完整记录排查链路、毒化机制（JVM 为什么会”握着旧文件视图”）、修复过程，以及顺手踩到的 Windows 临时端口坑。
一套 Spring Cloud 微服务 MES 里，一个”检验暂存”接口突然全量报错。报错很吓人：MyBatis 抛 BadSqlGrammarException，底层是 MySQLSyntaxErrorException: You have an error in your SQL syntax——语法错误，直指 mapper 写错了。但这条 SQL 在代码库里已经跑了很久，一行没改，而且”之前测试都是正常的”。
事后看，SQL 本身没有任何问题，问题出在 JDBC 连接串：换数据库时给 database.url 加了一个 ?sslMode=DISABLED 参数，和公共配置里追加的 ?allowMultiQueries=true 拼出了两个问号。驱动解析 URL 时只认第一个问号，第二个问号后面的整段参数被吞进前一个参数的值里——allowMultiQueries 这个键从未存在过，静默回退默认值 false，所有多语句 SQL 集体阵亡。
这个坑的迷惑性在于三层错位：报错在 mapper 层，根因在配置层；丢失的参数只有一个，其余功能全部正常；配置改完不会立刻炸，等到服务重启那天才引爆。这篇复盘把三层错位逐一拆开，重点讲清楚多语句 SQL 为什么天生依赖连接参数、双问号是怎么静默废掉它的。
本地开发环境的 MES（Spring Boot + EasyUI 微服务架构，部署在内网）突然报错：基础数据页点「下载导入模板」，接口抛 jcifs.smb.SmbAuthException: Access is denied.（jcifs 1.3.17）。模板存在文件服务器的 SMB 共享里，这行异常有两种完全不同的解读——“你的凭据我认了，但你不能进来”（授权问题），还是”你根本不是你”（认证问题）。两种解读指向的修法天差地别。
这类报错最怕一步跨错：看到 Access denied 就去改密码、重置账号、怀疑 NTLM 版本，改一圈发现方向全错。这次排查没有赌任何一个”想当然”的修复，而是用一个 20 行的 Java 探针把三种假设（账号密码错 / NTLM 协商不兼容 / 单共享 ACL 漏授权）逐一拆开，最后锁定第三种——文件服务器上单个共享目录漏了给服务账号授权，一条 icacls 修完当场生效，服务重启都不用。
这篇复盘完整定位过程，重点讲三个可复用的手法：denied 与 absent 的语义区分、同账号跨共享对比、修复后验证到与报错完全相同的操作层。
上一篇排查实录里（订单同步5分钟还锁死邻居接口），为了定位一个多语句大事务里到底哪条 UPDATE 吃掉了 300 秒，我用的第一步工具是 MySQL 内置的 profiling——一段 SET profiling = 1 加 SHOW PROFILES，给脚本里的每条 SQL 单独计时。有读者说从没接触过这个东西，这篇就把它从零讲透：五分钟上手、逐列读懂输出、以及几条不踩不知道的边界——包括它为什么测得出语句耗时、却测不到我最终要找的锁。
生产环境的数据同步服务连续报了三件事：ERP 订单同步单个任务跑了 317 秒；任务执行期间，产品同步接口直接 Lock wait timeout（等锁 50 秒超时）；再往前翻，还有一次 200 秒级别的死锁，innodb 状态转储里躺着 95 万行锁。三件事指向同一片代码，但三次现场的长尾耗时各不相同——130 秒、305 秒、317 秒，波动大得像玄学。
排查下来是两层问题叠在一起，彼此掩护：
@Async 是个摆设——整个模块没有 @EnableAsync，所有”异步任务”实际同步跑在 Tomcat 的 HTTP 请求线程里；最终修复只有两条 DDL 和一个配置类，本地实测单步耗时 48.9 秒 → 0.33 秒（约 150 倍），生产 7568 单全量同步从 317 秒回到 15.2 秒。这篇完整复盘两层问题的发现过程——尤其是中间那次”所有 EXPLAIN 都是毫秒级”的证据反转，差点让排查拐进死胡同。
“服务挂了为什么 Eureka 页面上还显示 UP？”、”自我保护的 85% 到底是怎么算出来的？”、”一个服务下线了，调用方最长要多久才感知到？”——这几个问题在面试和线上排查里出现频率极高，但多数回答停在”心跳续约、默认 30 秒”这一层。这篇直接拆开 Eureka 的源码（Netflix eureka-client / eureka-core 1.9.8，对应 Spring Cloud Greenwich 版本线，本地 maven 仓库的 sources 包就是最好的阅读材料），把注册、心跳、下线、剔除、自我保护、多级缓存、增量拉取、集群复制这条完整链路全部走一遍，每个结论都落到具体的类与方法上。
先给一个能贯穿全文的坐标系：Eureka Server 本质上是一个纯内存的租约登记表 + 一组围绕它运转的定时任务。理解了”注册表数据结构、租约的过期语义、缓存的刷新节奏”这三件事，所有”灵异现象”都能对号入座。