条件判断必须遵循“特异优先”原则：从上到下执行，一旦条件为真即进入对应分支且不再后续判断；因此应将范围最小、限制最严的条件（如score>=90）置于最前，避免宽泛条件（如score>=60）提前截断逻辑；数值区间推荐左闭右开写法以消除重叠与缺口。
这个问题本质是条件判断的执行顺序与业务意图不一致，导致本该触发的分支被前面更宽泛的条件“吃掉”，后续分支永远不执行——它不报错，但逻辑就悄悄失效了。
检查条件排列是否遵循“特异优先”原则
系统按从上到下的顺序逐条判断，一旦某个条件为真，就立即进入对应分支，不再往后看。所以必须把限制最严、范围最小的条件放在前面。
- 错误写法：
if score >= 60在前，elif score >= 90在后 → 所有 90 分都进第一个分支 - 正确写法：
if score >= 90先判，再elif score >= 60，最后补else处理不及格 - 在 Dify 工作流中，分支连线的上下顺序就是执行顺序，拖动调整时要肉眼确认逻辑层级
避免用 or 连接多个独立判断条件
像 if role == "admin" or "user" 这类写法在 Python 中实际等价于 if (role == "admin") or ("user")，而非空字符串恒为真，整个表达式永远成立。
- 应写成
if role in ["admin", "user"]或拆成两个独立分支 - 在 Dify 表达式中，
{{input.role}} === "admin" || {{input.role}} === "user"才是安全写法 - 只要涉及多个取值匹配，优先用数组包含判断，比堆砌 or 更可靠、易读、易维护
强制显式覆盖所有可能状态
不依赖“默认走 else”，而是把每个关键状态单独列为一个分支，并给每个分支打上可识别的标签（如 status: "pending", "approved", "rejected"）。
- Dify 中配置条件分支时，不要只留一个
else分支兜底，而是为每个业务状态设一条路径 - 即使当前只有三种状态，也明确写出三条分支，避免未来新增状态时被旧的 else 意外捕获
- 配合调试模式查看上下文输出，确认每个输入值确实落入你预设的某一分支，而非被模糊匹配吞掉
用区间图验证数值类条件是否重叠或留白
对年龄、分数、金额等连续型字段做多档判断时，边界值极易出问题。比如 >= 18 和 > 60 之间存在 [18, 60] 的灰色地带，而 > 60 和 >= 60 又会造成 60 这个点被两个条件同时命中。
- 把每条分支的判断条件转为数学区间，画在数轴上：如
score → (-∞, 60)，<code>score >= 60 && score → [60, 90) - 检查是否有重叠（两个区间交集非空）或缺口（相邻区间不衔接）
- 推荐统一采用左闭右开写法：
[60, 90)、[90, 100]，边界清晰不易错
