不能直接用lead()和lag()实现“逻辑门控分析”，二者仅为偏移取值函数，不执行布尔运算；真正的门控逻辑须由case、and/or等外部运算符构建，lead/lag仅提供参与运算的原始字段值。
不能直接用 LEAD() 和 LAG() 实现“逻辑门控分析”——这不是它们的设计用途，强行套用反而会掩盖真实问题、引入隐蔽错误。
LEAD() 和 LAG() 本质是偏移取值，不是布尔运算符
这两个函数只做一件事：按指定排序和分组，从相邻行“搬”一个值过来。它们不判断真假、不组合条件、不短路求值，也不生成布尔结果。所谓“门控”（如 AND/OR/NOT/XOR）必须由外部逻辑（CASE、AND/OR 运算符、或子查询）驱动，LEAD/LAG 只能提供参与运算的原始字段值。
- 常见误用：写
LEAD(status) = 'active' AND LAG(status) = 'inactive'就以为实现了“状态跃迁门”，其实这只是个普通布尔表达式，LEAD/LAG只负责把那两行的status拿过来 - 真正起“门控”作用的是
AND操作符本身，不是窗口函数 - 如果漏写
ORDER BY或错配PARTITION BY，拿到的就不是你认为的“前/后行”，整个逻辑就崩了
需要门控效果时，必须显式封装在 CASE 或 WHERE 中
比如检测“从 inactive 到 active 的首次切换”，关键不在 LAG，而在如何定义“切换”和“首次”。LAG 只提供上一行值，判断逻辑得靠你写：
SELECT *,
CASE
WHEN status = 'active'
AND LAG(status) OVER (PARTITION BY user_id ORDER BY event_time) = 'inactive'
AND LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time)
-
LAG(status)只返回字符串，不自动对比；= 'inactive'才是判断动作 - 必须加
LAG(event_time) 防止时间乱序导致误判（比如日志写入延迟） - 若没写
PARTITION BY user_id，不同用户的事件会混在一起排序，LAG就取到别人的数据
多层偏移组合极易出错，优先用 CTE 拆解
想表达“前一行是 A、当前是 B、后一行是 C”的三态约束？别堆三层 LAG/LEAD 在同一 SELECT 里。可读性和调试成本会指数上升：
- 错误写法：
LAG(x,1) = 'A' AND x = 'B' AND LEAD(x,1) = 'C'—— 看似简洁，但一旦ORDER BY有重复值，LEAD取到的未必是“紧邻下一行” - 推荐做法：用 CTE 先算出所有偏移列，再在主查询中组合条件
- 特别注意：SQL Server 和 MySQL 对
NULL的AND短路行为不一致，Oracle 默认不短路；依赖LAG(...,1) IS NOT NULL做前置过滤更安全
真正容易被忽略的点：偏移量为 0 是非法的（各数据库均报错），而偏移量大于分区行数时默认返回 NULL —— 如果你的门控逻辑依赖非空值，必须显式用第三个参数补默认值，比如 LAG(status, 1, 'unknown')，否则 status = 'active' AND LAG(...) = 'inactive' 整体为 UNKNOWN（即不满足）。
