租户编号01和1被合并，怎样检查限流键的归一化碰撞

租户编号01与1是否相同，应由权威身份规则决定，不能由限流代码顺手转成整数。大小写也一样。本文故意声明四个不同的虚构字符串ID，检查int和lower会不会把不同租户挤进同一个桶，不改变上游账号共享配额的业务政策。

先声明字符串身份的相等关系

附件权威集合是01、1、TeamA、teama，全部为字符串，四项彼此不同。JSON标准区分字符串与数字，但某个组织是否把这些字符串视为同一租户，仍是本地身份合同。本例明确保留前导零和大小写，不声称New API或其他产品的真实租户编号采用这种格式。

错误候选算法把纯数字串转成整数再转回字符串，把其他串转小写。于是01和1都成为桶1，TeamA和teama都成为桶teama。运行器输出从候选桶到原始身份的分组，两个组都有两名不同权威ID，因此都是未经授权的多对一碰撞。只比较映射前后总请求量，可能看不到这类身份误合并。

碰撞检查应在启用新键之前完成

把每个原始ID映射到候选键，再反向分组；若一组包含多个按权威规则不同的身份，应停止启用或提交人工业务确认。不能先让它们共用限额，等用户被错误限流才说明“系统自动规范化了”。映射迁移还应记录版本，便于解释历史桶与新桶分别对应谁。

安全参考键使用类型域tenant与原始ID组成二元组，四项得到四个桶。真实持久层若只接受字符串，应使用无歧义的结构化编码，而不是随意用一个可能出现在ID里的分隔符拼接。还要检查存储的排序规则、大小写比较和长度截断，不能在应用端保留了区别，却在数据库索引或缓存层再次合并。

未知ID不靠长相推断归属

未知001虽然转整数也是1，参考函数仍拒绝unknown-authoritative-id，不能自动归到权威租户1。这能抓住“先规范化再查身份表”的危险顺序。查询应先按权威接口解析身份，再取得已授权的稳定标识，不能让未经核验的请求字段直接决定限流桶。

多个虚拟Key合法映射到同一账号配额域，是明确业务映射；本篇检查的是没有授权依据的字符归一化，两者不能混为一谈。实际执行只对合成ID做映射、碰撞分组和未知拒绝，没有修改网关或测试分布式限流。交付结果是两个碰撞组、安全桶四个及未知ID拒绝。接入自己的身份格式前先写清相等关系，再复核所有存储层，才能避免一次看似友好的“统一格式”改变租户隔离。

配套样本与复核入口

下载本篇独立合成输入和实验运行器。上述文件放在同一目录后运行 python run_lab.py C005。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

资料核对日期：2026-10-24。官方依据1。

与本站相关基础教程的区别：旧文解释组织共享池和多Key共配额；新题查未经授权的字符串归一化碰撞，不改变真实账号配额政策。