I4.07.1per-feature freshness设计
不同功能对数据实时性的要求不同，无需所有内容统一追求最新
别名: 分功能实时 · freshness by feature · 不必处处最新
概念解释
会话里的新消息晚一秒就会被当成断线；个人资料上的头像晚一小时，几乎没人当故障。不同功能对实时性的要求不同：每一块界面有自己的「还算新鲜」的预算，不必把整站推到同一条「永远最新」。通道能做到多快，和这块内容需不需要那么快，是两笔账。
机制
功能绑的是不同的决策。正在进行的对话、协作光标、支付余额，决策用的就是这一秒的值，旧一拍会做错事。设置页、帮助文档、昨天的报表，决策用的是结构稳定的那一版，刷到秒级没有新的决策收益，只有请求和重绘的成本。把所有功能对齐到最严的那一档，是在用最贵的通道去养最不在乎新鲜度的表面。
「功能」的粒度要落到可独立刷新的一块，而不是一个产品名。同一屏里，消息流、在线人数、侧栏广告、底部版权，四块的预算可以差出几个数量级。统一追求最新，往往来自「我们上了推送」这种能力侧的理由，不是来自这块会做错什么。
边界
合规快照、日终对账、考试试卷，最新会破坏「这一刻冻结」的产品约束，实时性预算是上限为零的更新，不是越新越好。事故状态、风控开关这类安全功能，预算会临时抬到最严，平时的分档不能挡住这一抬。多设备同时写同一份文档时，每一端都觉得自己是「正在进行」，分档若把一端当静态资料，冲突会在那一端被当成新鲜度问题，其实是写入冲突。
怎么落地
- 给每块可独立刷新的界面写一档预算：即时、数秒、数分钟、按会话、按天。对着「旧了会做错什么」写，不要对着技术栈写。
- 只把最严的那几块接到高成本通道；其余用更疏的刷新或进入时拉一次。
- 同一屏允许不同档并存，不要为了侧栏最新把整页推成推送。
- 验证：把非关键块的刷新降到进入时一次，关键路径（会话、余额）仍保持即时。关键路径变旧应被当成故障；资料页变旧一小时不应进故障单。把整站都接到即时通道作为反例，看非关键块的请求量有没有收益。