版本支持：v2.16.1+

要求Nacos Server 2.x及以上

并发发布的原子性靠publishConfigCas来保证，1.x没有这个能力。

这个模块显式用的是nacos-client:2.5.3，而旧的liteflow-rule-nacos插件还在用1.4.4，所以迁移的时候不要把两个模块放进同一个classpath。如果外部BOM把客户端降级到不含CAS API的版本，模块会在初始化时直接报错。

Step 1：引入依赖

<dependency>
    <groupId>com.yomahub</groupId>
    <artifactId>liteflow-spring-boot-starter</artifactId>
    <version>2.16.1</version>
</dependency>
<dependency>
    <groupId>com.yomahub</groupId>
    <artifactId>liteflow-rule-db-nacos</artifactId>
    <version>2.16.1</version>
</dependency>

Step 2：写配置

这里要定两件事：插件用哪个客户端连Nacos，以及规则记在哪个隔离名下。两者没有关联。

先说连接。项目已经接了Nacos配置中心的话，连接一行都不用配，插件按类型把容器里的ConfigService取出来直接用，连接、鉴权、命名空间都沿用这个bean。有多个ConfigService时，用config-service-bean-name指明用哪个。复用的bean归容器所有，Provider关闭时不会去调它的shutDown()。

容器里确实没有ConfigService，那就配地址让插件自己建：

liteflow.rule-db.nacos.server-addr=127.0.0.1:8848
# namespace 填命名空间ID，不是显示名称；留空使用 public
# liteflow.rule-db.nacos.namespace=your-namespace-id
# group 默认 LITEFLOW_RULE_DB
# data-id-prefix 默认 liteflow-rule-db

顺序上bean优先于server-addr，找到了bean就不会再看server-addr；两个都没有则启动报错。

再说隔离名。liteflow.rule-db.application-name直接决定Catalog的dataId，不同取值互相看不到。它只管隔离，和用哪个客户端无关。

Spring Boot下它留空时会取spring.application.name：

spring.application.name=order-service

两个都没配会回落成default，多个应用共用一套Nacos时请确保取值不同。Solon插件没有这个回落，需要显式配liteflow.rule-db.application-name。这个值还要和Step 3里Publisher的applicationName(...)一致。

运行时会把当前应用映射成一条Nacos配置：

dataId = {data-id-prefix}.{application-name}.catalog.json
group  = {group}

举个例子，应用名是order-service时，默认的dataId就是liteflow-rule-db.order-service.catalog.json，group是LITEFLOW_RULE_DB。这条配置不用你在控制台预先建好，首次发布时Publisher会创建。

Step 3：发布第一条规则

规则的增删改只能走Publisher API。正文、版本、sequence和lastChange都在同一次CAS里提交，在控制台手改是覆盖不了这套并发语义的，本页末尾有说明。

import com.yomahub.liteflow.publisher.PublishChainRequest;
import com.yomahub.liteflow.publisher.RulePublisher;
import com.yomahub.liteflow.publisher.RulePublisherFactory;
import com.yomahub.liteflow.repository.nacos.NacosPublisherConfig;

try (RulePublisher publisher = RulePublisherFactory.create(
        NacosPublisherConfig.builder()
                .serverAddr("127.0.0.1:8848")
                .applicationName("order-service")
                .build())) {
    publisher.publishChain(PublishChainRequest.builder()
            .chainId("orderChain")
            .el("THEN(a, b)")
            .expectedVersion(0L)
            .build());
}

每次发布会先读取当前的Catalog，再通过Nacos的CAS整体替换。Catalog里的正文、业务版本、全局sequence和lastChange都在同一次CAS里提交。并发写入产生冲突时会重新读取再重试，最多8次；如果你显式传了expectedVersion而它已经失效，则抛VersionConflictException。

执行节点通过Nacos Listener感知lastChange，一旦发现序号跳跃、内容损坏或者回调失败，会立即请求一次全量对账。

容量必须提前评估

一个应用的全部chain和脚本正文都在同一条Nacos配置里，受Nacos服务端nacos.core.config.max-size、数据库字段以及接入层的单配置大小限制，而模块不会自动分片。

所以上线前请用生产等价的配置压测一下Catalog的最大体积，并预留增长空间。如果规则数量多、正文很长或者发布频繁，建议优先选SQL、PostgreSQL或MongoDB。

执行端不会长期保留整份Catalog正文，但每次冷读取和对账都要传输并解码整份配置。

不要在控制台直接改Catalog

正确的发布要基于当前内容的MD5做CAS，同时维护正文MD5、业务版本、连续的sequence和lastChange，控制台的覆盖写保持不了这套并发语义。请只用RulePublisher。

Step 4：执行

和前面一样，照常调flowExecutor.execute2Resp(...)。