这种业务场景有没有更优雅的方式？

[LuciusChen]

后端： 判断 3 依赖判断 1 添加的数据。

// 判断 1 为提示信息，确定后跳转下个页面
if (condition){
    result.setCode("0002");
    result.setMsg("msg");
    return result;
}
// 判断 2 为校验数据是否存在，前端给出弹框，确定后自动添加数据，并跳转下一个页面。
if (condition){
    result.setCode("0001");
    result.setMsg("msg");
    return result;
}
// 判断 3 同样为提示信息，确定后跳转下个页面。
if (condition){
    result.setCode("0003");
    result.setMsg("msg");
    return result;
}

前端： 普通情况下，三个提示都是单一提示。 但也会出现需要顺序提示的情况，比如：

1. 满足判断 1 ，前端提示，判断 1 前端确定后，如果条件满足提示判断 2 ，确定后添加数据并提示判断 3 ，确定后跳转下一个页面。
2. 满足判断 2 ，前端提示，判断 2 前端确定后，满足判断 3 提示，确定后跳转下一个页面。

---

目前上述判断都在后台同一个接口内，涉及到顺序提示的时候，前端调用后台代码就需要在对应的 code 分支内重复调用该接口。

判断 1 在第一次点击确定后，后续接口不再校验该场景。如果重新进入该页面，则判断 1 对应场景需重新校验。

[3dwelcome]

"前端调用后台代码就需要在对应的 code 分支内重复调用该接口。"

我觉得业务逻辑没什么问题，但是你前端重复请求那就有问题了。

可以考虑把前端的几次请求，打包合并成一个后发送，然后按照多个命令的形式来解析。

[InkAndBanner]

没有什么是加状态不能解决的 如果有 那就加两个

[ccraohng]

看起来是不同的逻辑，有不同的连续执行逻辑单元
每个执行单元统一封装成 promise 函数，丢到 map 里，然后不同入口拿到各个函数，用数组串联起来执行

[66beta]

我觉得可以找产品经理再理一下业务逻辑

[LuciusChen]

@3dwelcome 不能打包一起，因为要让用户感知，而且其中一个提示确定后还会新增数据，这个数据是后续判断的前提。

[iamzuoxinyu]

按[(cond, code, msg)]打表，在复杂就写成状态机。

[LuciusChen]

@iamzuoxinyu 打表？没懂。。。（尴尬