一个前置路由功能部署上线后，实际请求全部未命中——配置在、数据在、代码在，就是不走那条分支。
根因一：状态字段没声明，框架静默忽略
状态图里新增了一个字段，用来标记「这一轮是否被前置路由命中」，条件边读它决定去向。但状态类型的定义里漏了声明这个字段。
框架的做法是静默忽略未声明的字段——于是条件边永远读到空值，永远走默认分支。没有异常、没有警告，日志里只有一句「没有命中」。
这是这类框架最阴的坑：字段不存在不会报错，只会让所有判断悄悄走向错误的分支。
根因二：类型看着对，生成的 SQL 不对
业务缓存表里存的是 JSONB，而模型层声明成了普通 JSON。调用「包含匹配」时，生成的 SQL 变成了对 JSONB 做字符串 LIKE，直接报错。
教训是：ORM 的字段类型要和数据库的真实类型逐字对齐，尤其是 JSON / JSONB、数组、时间这些容易「看起来一样」的类型。
根因三：两个条件互相矛盾
过期判断写成了「未设置过期时间 并且 过期时间大于现在」——这两个条件永远不可能同时成立，于是缓存永远查不到。
复杂布尔表达式，写完要用真值表走一遍——「读起来对」和「逻辑上对」是两件事。
附带的一个性能发现
排查过程中还发现：状态持久化的初始化会让启动卡住 30 秒。定位到是事件循环模型与数据库驱动之间的兼容问题，跳过它之后启动降到 0.3 秒。
修复后的结果
8 个用例全部命中，图内耗时从 2-5 秒降到 0.1-0.4 秒，其中 7 个用例完全没走大模型。
三个根因没有一个是「逻辑写错了」，全都是「以为它在工作，其实没有」。这也是后来养成的一个习惯：凡是没有报错却没有生效的功能，先怀疑静默路径。