关键路径计算必须先建模任务依赖关系，再用递归cte结合lag()、max()over()和rows unbounded preceding求解；仅靠窗口函数无法替代显式依赖定义与逻辑排序。
关键路径时长不能直接用单个窗口函数“一键算出”，必须先建模任务依赖关系，再用递归 CTE + 窗口函数组合求解；LAG()、MAX() OVER() 和 ROWS UNBOUNDED PRECEDING 是核心支撑点。
关键路径建模必须显式定义前置任务
SQL Server 不支持原生的项目网络图（AOA/AON）解析，所有关键路径计算都依赖你已有的任务表结构。常见错误是直接对 StartDate/EndDate 做聚合——这只能算总工期，不是关键路径。
- 任务表至少需包含：
TaskID、Duration、PredecessorID（或PredecessorList字符串），否则无法推导逻辑依赖 - 若用字符串存多个前置任务（如
'T1,T3'），必须先用STRING_SPLIT()拆解，再 JOIN 回任务表，否则LAG()无法定位前驱 - 没有
PredecessorID字段？那关键路径在数据库层不可计算——这不是窗口函数能补救的缺失设计
MAX() OVER(ORDER BY StartDate ROWS UNBOUNDED PRECEDING) 计算最早开始时间
关键路径本质是“最早开始时间 + 工期”的链式传播。窗口函数在这里替代了循环或游标，但必须严格按依赖顺序排序，不能只按 TaskID 或自然插入序。
- 排序字段必须是逻辑执行序：通常是
Level（由递归 CTE 算出的层级）+TaskID，而非原始StartDate（它可能是计划值，未反映依赖） -
ROWS UNBOUNDED PRECEDING表示从分区首行累加，对应“所有前驱任务最早完成时间的最大值”；用RANGE会因重复排序值导致错误聚合 - 示例片段：
SELECT TaskID, Duration,<br> MAX(EarliestFinish) OVER (PARTITION BY ProjectID ORDER BY Level, TaskID ROWS UNBOUNDED PRECEDING) AS EarliestStart<br>FROM task_schedule
LAG() 只适用于线性依赖，复杂并行必须用递归 CTE 预处理
很多人试图用 LAG(EarliestFinish) OVER (ORDER BY ...) 直接取上一任务结束时间，这仅在单链任务（无分支/合并）下成立。实际项目中，一个任务可能有多个前驱，它的最早开始时间取决于所有前驱中最晚完成的那个。
-
LAG()最多取一个前驱值，无法表达MAX(LAG1, LAG2, LAG3)—— SQL Server 窗口函数不支持跨多行取聚合极值后再参与当前行计算 - 正确做法：先用递归 CTE 展开所有前置路径，生成
TaskID → PredecessorID → Duration的扁平关系，再对每个TaskID分组MAX(PredecessorFinish) - 别省略
PARTITION BY ProjectID：多项目共库时，漏写会导致跨项目污染计算结果
浮动时间（Float）计算容易忽略 LAST_VALUE() 的默认帧范围
关键路径上的任务浮动时间为 0，非关键路径需计算 LatestStart - EarliestStart。而 LatestStart 依赖项目总工期反推，此时 LAST_VALUE(EarliestFinish) 常被误用。
-
LAST_VALUE()默认帧是RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，这意味着它只看“当前行及之前”，不是整个分区末尾——必须显式指定ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING - 更稳妥的做法是先用子查询或 CTE 算出项目总工期（
MAX(EarliestFinish)），再用该值减去各任务工期倒推LatestStart，避免帧范围陷阱 - 注意时区与日期类型：
datetime的精度为 3.33ms，若任务时长精确到分钟，建议统一转为datetime2(0)或用DATEADD(MINUTE, ...)计算，防止浮点累积误差
关键路径真正的难点不在窗口函数语法，而在把项目管理逻辑准确映射成关系代数：依赖必须可枚举、排序必须反映执行约束、浮动时间必须双向校验。窗口函数只是高效实现工具，不是自动推理引擎。
