考察点
这道题接着时间语义往下挖：窗口什么时候算「可以出结果了」，判晚来的数据怎么办。面试官想听到的是完整的迟到处理体系，而不是单点答案。追问常往自定义 Trigger、allowedLateness 的重复触发语义、侧输出流的下游处理走。
参考答案
Trigger：窗口的闹钟
触发器决定窗口「什么时候计算、什么时候清理」。窗口算子对每条数据都会问 Trigger 一次，Trigger 返回四种结果：CONTINUE（不动）、FIRE（触发计算但不清状态）、PURGE（清状态不计算）、FIRE_AND_PURGE（计算并清理，最常见的最终触发）。
内置触发器里最重要的是三个。EventTimeTrigger：Watermark 超过窗口结束时间就 FIRE_AND_PURGE，这是事件时间窗口的默认行为；配了 allowedLateness 后，宽限期内的迟到数据会让它再次 FIRE（更新结果），Watermark 超过「结束时间 + 宽限期」才真正清理。ProcessingTimeTrigger：按机器时钟注册定时器触发。CountTrigger：攒够 N 条触发，常配在 GlobalWindow 上。Trigger 还能注册两种定时器（事件时间定时器由 Watermark 驱动，处理时间定时器由系统时钟驱动），自定义 Trigger 的本质就是在这两个回调里编排 FIRE/PURGE 时机。
迟到数据的三层处理
第一层，Watermark 本身是乱序容忍度。forBoundedOutOfOrderness(10s) 意味着 10 秒内的乱序不算迟到，正常进窗口。这一层决定的是「什么算迟到」。
第二层，allowedLateness。Watermark 已经过了窗口结束时间，但宽限期（比如 1 分钟）内迟到的数据仍然进窗口，每来一条触发一次更新，下游会收到修正后的结果。这层要配合幂等或可更新的 sink——数据库主键 upsert 可以，往 Kafka 追加就得下游能去重或接受更新语义。
第三层，侧输出流（Side Output）。sideOutputLateData(lateTag) 把超过宽限期的数据分流出来，通常落 Kafka 或 OLAP 表，离线任务定时补偿，或者人工审计。金融对账类场景这一层是刚需，实时链路宁可迟到数据走补偿，也不能丢。
一个完整的例子
实时统计每 5 分钟的订单金额：事件时间 + 滚动 5 分钟窗口 + Watermark 容忍 10 秒乱序 + allowedLateness 1 分钟 + 迟到数据进侧输出写补偿表 + sink 按窗口主键 upsert 到 MySQL/Doris。这套组合在绝大多数业务里够用了。
工程上的坑
allowedLateness 会把窗口状态的存活时间拉长到「窗口长度 + 宽限期」，状态量要算进去。另外 allowedLateness 的重触发语义是「每条迟到数据都触发一次」，迟到风暴时下游会被刷爆，必要时用自定义 Trigger 改成定时合并触发。还有一个容易混的点：迟到判定只在事件时间窗口里有意义，处理时间窗口没有「迟到」概念。
可能的追问
- 什么时候需要自定义 Trigger？——内置组合满足不了时，比如「每来 100 条先输出一次中间结果、Watermark 到了再出最终结果」，或者业务要求处理时间兜底（事件时间一直不推进也要出数）。
- 侧输出的数据怎么用？——常见是写一张迟到明细表，由离线任务合并回最终表做修正；低频场景直接告警人工介入。
- Watermark 一直不推进会怎样？——窗口永远不触发，状态越积越多。排查方向：是否有空闲分区没配 idleness、上游是否持续有数据、WatermarkStrategy 时间戳提取是否正确。