Go SSE 断线重连如何避免重复事件：Last-Event-ID、游标与幂等消费

线上通知流最难排的不是“连接能不能建立”，而是用户刷新页面或网络抖动后，事件到底从哪里继续。Go 的 SSE 服务如果只把消息写进连接，断线期间的事件会漏掉；如果每次重连都从最新事件开始，又可能让客户端重复处理。比较稳妥的边界是：服务端给每条事件分配递增 id，客户端保存最后一次确认的 ID，重连时通过 Last-Event-ID 请求缺口，再用业务事件 ID 做幂等保护。

为什么只重连最新数据会漏掉 SSE 事件

SSE 的连接是持续响应。服务端写出一条事件后，客户端可能已经收到，也可能卡在代理缓冲、移动网络切换或浏览器进程恢复阶段。若服务端只维护一个“当前状态”，重连时直接返回最新状态，客户端看不到中间发生的通知；若服务端完全不保存事件，又无法判断缺口。

因此服务端至少要有一个短期事件日志。事件格式可以很小：

type: order.updated
id: 1042
retry: 3000

data: {"order_id":"A-19","status":"paid"}

这里的 1042 才是恢复依据。它应该在同一业务流内单调递增，并且和事件内容一起写入可查询的环形缓冲、数据库表或其他可靠存储。

Go 服务端如何按 Last-Event-ID 补发缺口

浏览器重连时会带上上一次收到的事件 ID。Go 里先读取请求头，再决定从哪个游标开始发送：

func stream(w http.ResponseWriter, r *http.Request) {
    flusher, ok := w.(http.Flusher)
    if !ok {
        http.Error(w, "stream unsupported", http.StatusInternalServerError)
        return
    }
    w.Header().Set("Content-Type", "text/event-stream")
    w.Header().Set("Cache-Control", "no-cache")
    lastID, err := parseLastEventID(r.Header.Get("Last-Event-ID"))
    if err != nil {
        http.Error(w, "invalid Last-Event-ID", http.StatusBadRequest)
        return
    }
    for _, event := range history.After(lastID) {
        fmt.Fprintf(w, "id: %d\ndata: %s\n\n", event.ID, event.Data)
        flusher.Flush()
    }
}

history.After(lastID) 的语义必须是“严格大于 lastID”。如果写成大于等于，客户端会再次收到已处理的那条事件；如果服务端先删除旧事件，则要能返回“游标过期”，让客户端重新拉取完整快照，而不是静默从最新位置开始。

游标恢复不等于消息只会到达一次

网络断线发生在“客户端收到事件”和“客户端完成业务处理”之间时，服务端无法知道客户端是否已经落库。重连补发同一个 ID 是正常的至少一次投递结果。客户端可以先按业务事件 ID 去重：

func applyOnce(e Event) error {
    if seen.Contains(e.ID) {
        return nil
    }
    if err := store.Apply(e.Data); err != nil {
        return err
    }
    return seen.Mark(e.ID)
}

生产环境不要只把 seen.Mark 放在进程内 map 里。重启、多个实例和消费重试都会让本地集合失效。更可靠的做法是让业务写入和幂等键落在同一个事务边界，或者用数据库唯一键、Redis 的短期去重键保护重复请求；选哪种方案，取决于事件保留时间和业务能接受的重放窗口。

三组日志可以验证重连链路是否完整

测试时可以在事件写出后立刻断开连接，再用同一个 Last-Event-ID 重连。别只验证浏览器控制台有新消息，还要检查订单表、通知状态或其他真实副作用是否只变化一次。

常见问题

SSE 的 Last-Event-ID 可以用时间戳吗？

可以编码成可排序的游标，但不建议直接使用毫秒时间戳。并发写入时可能碰撞，跨实例时也未必单调；递增序列或带分区信息的事件 ID 更容易判断缺口。

事件已经过期时，服务端应该怎么响应？

明确返回游标过期状态，让客户端先获取当前完整快照，再把快照版本作为新的恢复基线。静默跳到最新事件会把中间变化伪装成“从未发生”。

客户端去重后还需要服务端保存历史吗？

需要。客户端去重只能防止重复副作用，不能找回断线期间完全没有收到的事件；服务端历史和客户端幂等是两个互补层次。

把恢复边界写进接口契约

可靠的 Go SSE 实现不靠某次网络测试碰巧通过。接口要写清楚事件 ID 的生成范围、历史保留窗口、游标过期响应和客户端幂等键。这样即使连接在最尴尬的时刻断开，重连链路也能把“漏消息”和“重复处理”分别交给正确的机制处理。