Sentinel 控制台能把 JSON 写进 Nacos，客户端却没有加载规则，先检查配置内容与客户端转换器的约定。控制台保存的管理实体，不一定就是客户端应该读取的运行规则。

当时发生在规则转换阶段

旧项目按社区方案改造 Dashboard，经 Nacos 持久化流控规则。日志显示数据源内容没有按预期转换成 FlowRule，最终得到 0 条规则。

当时发布的是 FlowRuleEntity，其中除了资源与阈值，还带有控制台管理字段：id、app、ip、port、gmtCreate、gmtModified。原记录在这些字段上加 Fastjson 的序列化排除注解，重新构建控制台后，客户端加载恢复。

序列化排除处理的写法

下面展示当年的字段处理结构，使用的是 com.alibaba.fastjson.annotation.JSONField，不是 Jackson 的同名配置：

public class DashboardMetadata {
    @com.alibaba.fastjson.annotation.JSONField(serialize = false)
    private Long id;
    @com.alibaba.fastjson.annotation.JSONField(serialize = false)
    private String app;
    @com.alibaba.fastjson.annotation.JSONField(serialize = false)
    private String ip;
    @com.alibaba.fastjson.annotation.JSONField(serialize = false)
    private Integer port;
    @com.alibaba.fastjson.annotation.JSONField(serialize = false)
    private java.util.Date gmtCreate;
    @com.alibaba.fastjson.annotation.JSONField(serialize = false)
    private java.util.Date gmtModified;
}

片段只说明六个字段的注解方式，不是完整 FlowRuleEntity 替换类。它只影响使用该注解的 Fastjson 序列化路径，并不等于所有 JSON 库都按此排除，也可能影响同实体的其他管理接口。

更清楚的边界是在发布入口把管理实体显式转换成运行规则，再序列化。这样管理页需要的 ID、机器与时间仍可保留，不必让一个对象兼任两种协议。

对照客户端实际需要的内容

例如普通单机 QPS 规则可表示为下面的数组；资源名必须与实际资源一致，阈值由业务决定：

[
  {
    "resource": "echo",
    "limitApp": "default",
    "grade": 1,
    "count": 10,
    "strategy": 0,
    "controlBehavior": 0
  }
]

这是规则形状示意，不是让生产系统直接采用该阈值。还要核对客户端订阅的 namespace、group、dataId、规则类型，以及顶层是数组还是额外封装的对象。

发布成功与加载成功分别检查

Push 模式的方向是“控制台或配置管理入口 → 配置中心 → 客户端数据源 → RuleManager”。控制台写成功，只证明上半段，不证明客户端取到了正确内容。Sentinel 生产规则管理

额外 JSON 字段是否会导致失败，取决于实际转换器和版本；当年的处理结果不能证明“存在任意多余字段必定失败”。面对 0 条规则，应保留脱敏的原始配置和转换异常，比较发布前后内容，而不是反复提高阈值或关闭限流。