H5.10.1per-category frequency caps设计研究
不同类别的通知应有各自独立的频次上限而非共享总额
别名: 分类频次上限 · 独立配额 · separate budgets
概念解释
频次上限应按类型各算各的，而不是全应用共一个总额。聊天把共享额度用完之后，安全警报或取件码还得能发出；营销把额度用完，不应把订单更新也卡住。共享总额把高后果与低后果绑在同一只计量器上，先到的占用者决定后到的命运。
这条是配额怎么切。它不是「总量太高会触发整应用关闭」——那是关闭漏斗；也不是时区与作息怎么选钟点。
机制
总额假设所有到达可互换。人的损失函数不可互换：少一条验证码和少一条推荐不是同一损失，多一条闲聊和多一条风控也不是同一打扰。共用计量器时，高频低后果类型会挤占低频高后果类型，产品侧还会用「今天已经推过了」挡住本不该挡的那类。独立上限让每类有自己的饱和点，挤占被隔离。
独立不是无限。每类仍有上限，只是超了只停该类，其他类的计量器不动。安全类的上限可以极高或没有，营销类可以极低——这是配额形状，不是再做一个总开关。
怎么研究
给混合到达设「每日共 N 条」对「每类各 n 条」，看高后果类型在聊天高峰日是否被挡住，以及营销是否在事务额度下仍能打满总额。
自变量：配额是共享还是按类、各类上限形状、高后果是否可超限。 因变量：高后果被配额丢弃的条数、营销占用共享额度的比例、随后的类型关闭与总关。
实验室流量均匀，测不到挤占。要用真实的突发（群聊高峰）再插入一条安全事件。不要用总到达数当守纪——共享总额可以守纪同时把错误的类挤掉。
边界
只有一类的应用，独立上限退化为总额，不必硬造分类。跨类型的摘要（「你有 3 件事」）若仍按一条发送，应计入哪一类要事先规定，避免摘要成为逃避营销上限的漏洞。法定送达不应被任何产品配额丢掉，配额要用完时丢掉的是可推迟类。
怎么落地
- 为每类设独立计数器；超限只静默或推迟该类。
- 安全与时效事务不与营销、成就共享计量器。
- 仪表盘按类显示今日已用/上限，而不是只显示一个全家桶数字。
- 验证：把聊天类打满其上限，再发一条取件码和一条促销。取件码应到达，促销应被自己的上限拦住或本来就低。若取件码也没到，额度就是共享的。