在 SQLite 的递归 CTE 中，改成 UNION 后相同结果不再反复入队，关键在入队前的整行比较。初始查询先把行放入队列，递归查询产生新行时，UNION 只在此前没有相同整行加入过队列时允许入队；已经取出队列的旧行仍参与排除。因此同一整行不会第二次入队，也不会由它再次推进递归。UNION ALL 则保留重复。这里比较整行，不是业务 ID；深度列等字段若在SQL重复比较意义上不同，整行就不再相同；不能仅凭显示写法不同判断不重复，不能把 UNION 当成任意递归都会停止的依据。
适用：这段机制说明适用于襄阳樊城区台式电脑上经授权开展的 SQLite 查询、代码和去敏日志只读核对，重点看递归 CTE 的初始查询、递归查询及连接运算符。按 SQLite 官方当前说明理解行为，实际库版本和复合 recursive-select 等特性另行核对；核对时不执行客户查询、不写库、不改数据。
观察：先确认是否为 WITH RECURSIVE，以及初始查询与递归查询之间用 UNION 还是 UNION ALL；若为 UNION，按入队前去重理解，若为 UNION ALL，按保留重复理解。再对照去敏日志中的队列变化和递归表增长，看重复行是在入队前被丢弃，还是入队后才被取出；若旧行已出队而相同整行不再出现，说明排除范围包含此前入队的历史行。随后逐列比较被怀疑相同的行，尤其看业务 ID 之外的深度、路径、时间或状态列；若这些列有变化，整行不同，去重条件不会命中。最后检查 WHERE 边界、LIMIT、OFFSET、路径防环或业务约束是否真正限制递归；若仅依赖 UNION 而深度列持续递增，应把队列继续增长视为需要进一步核对的结果条件。
风险：最常见的是把业务上相同误当成整行相同。业务 ID 相同但深度列变化时，UNION 仍可能允许新行入队，队列会继续产生后代行，带来 CPU、内存或临时存储压力；若没有明确边界，不能把 UNION 当成任意递归都会停止的依据。UNION ALL 会保留重复整行，重复推进更直接。判断重复时 NULL 值按彼此相等处理，不与其他值相等；若业务逻辑把 NULL 当作未知且不应合并，结果会与预期不同。旧版本对递归查询中复合查询的支持也有差异，实际版本需另核。
下一步：先做只读材料整理，提供去掉连接串、账号、文件路径、客户名称等敏感信息后的完整 CTE 语句，注明实际 SQLite 版本，附相关表结构、索引和脱敏后的队列增长日志，并说明当前连接运算符、边界条件与期望停止条件。材料齐备后可在襄阳樊城区台式电脑场景中逐项比对，确认是整行差异、NULL 比较还是缺少边界导致队列继续推进。需要咨询可拨打 400-877-9605；电脑快修网是信息展示与第三方维修对接平台，实际范围和安排需确认。