考察点
窗口是流聚合的基本工具，这道题考的是语义理解加场景匹配能力：四种窗口各自怎么切分数据、状态开销差在哪、什么业务用什么窗口。追问常往滑动窗口的状态放大、会话窗口的 gap 语义、全局窗口配触发器的用法走。
参考答案
时间窗口：滚动与滑动
滚动窗口（Tumbling Window）把数据流切成不重叠的固定长度段，每条数据只属于一个窗口。window(TumblingEventTimeWindows.of(Time.minutes(5))) 就是每 5 分钟一段：日报表、每 5 分钟 PV/UV 这类「整点对齐」的统计都是它。状态开销最小，一条数据更新一个窗口状态。
滑动窗口（Sliding Window）由窗口长度和滑动步长两个参数定义，比如窗口 10 分钟、每 1 分钟滑一次，一条数据会同时属于 10 个窗口。它回答的是「最近 10 分钟的指标，每分钟刷新一次」这类需求——监控大盘上的近 N 分钟曲线都是这么算的。代价是状态放大：窗口数 = 长度/步长，长度 1 小时、步长 1 分钟就是 60 倍的状态和计算量。滑动窗口太大步长太小时要掂量，或者改用两阶段聚合、或者干脆用滚动小窗口加外部累加来近似。
会话窗口
会话窗口（Session Window）不按固定时间切，按「活跃间隔」切：同一个 key 的数据，相邻两条间隔超过 gap（比如 30 分钟）就断开成两个会话窗口。典型场景是用户行为会话分析——一次 App 使用会话里的点击聚合在一起算时长、算步骤数。会话窗口的窗口边界随数据动态变化，底层靠窗口合并实现：新来的数据如果落在已有两个窗口之间把它们「桥接」起来，就合并窗口和状态。gap 设多大是个业务问题，常参考用户行为间隔的分布来定，比如 P95 的操作间隔。
全局窗口与 CountWindow
全局窗口（Global Window）把所有数据扔进一个永不自动结束的窗口，必须自己配 Trigger 决定何时触发、何时清理。它是个半成品工具，适合触发逻辑完全自定义的场景，比如「攒够 1000 条或满 5 分钟就输出一批」。计数窗口（CountWindow）按条数切，每 100 条一个窗口，注意它是 key 内计数的，key 分布不均时某些 key 的窗口可能长期凑不满。
窗口的两个维度
选型时记住两个维度。时间语义维度：事件时间窗口受 Watermark 驱动，结果确定；处理时间窗口按机器时钟切，简单但不可重放。划分方式维度：key 内划分（keyBy 后每个 key 独立开窗）还是全流划分（windowAll，并行度为 1，慎用）。生产上绝大多数是 keyBy + 事件时间 + 滚动/滑动，会话窗口按需，windowAll 基本只在小流量场景出现。
增量聚合
窗口配 ReduceFunction/AggregateFunction 是增量聚合，状态里只存一个累加器；配 ProcessWindowFunction 是全量聚合，窗口数据全存下来触发时一次性处理。能增量就增量，ProcessWindowFunction 和增量函数组合用（拿到累加结果再做窗口级加工）是最优写法。
可能的追问
- 滑动窗口状态放大怎么缓解？——缩小步长比、改用预聚合（先小滚动窗口再合并）、或者评估 RocksDB 状态后端扛住放大后的状态量。
- 会话窗口能提前输出吗？——窗口本身等 gap 超时，想提前看到中间结果要自定义 Trigger 或改用 ProcessFunction 手动管理会话状态。
- 窗口状态什么时候清理？——窗口触发且过了 allowedLateness 后清理；状态 TTL 是另一层兜底，别把 TTL 设得比窗口周期还短，会把状态提前清掉。