同一段业务语义，可能被客户端编码成不同的 HTTP 请求：Content-Type 的参数顺序不同、JSON 对象字段顺序不同、全角与半角字符混用，甚至一个“é”可由两种 Unicode 组合表示。若中转站把原始字节同时用于签名、缓存、配额和审计，系统会把“同一请求”误判为多份请求；反过来，过度改写又会破坏上游协议兼容性。
先划清可规范化的边界
传输层应保留原始请求以便排障，同时派生一份“业务比较视图”。通常可以安全统一 Header 名称大小写、合并重复空白、解析 JSON 后再按固定规则生成哈希。不能擅自改变的包括签名覆盖范围、流式正文、二进制附件、上游明确区分空字段和缺失字段的接口。尤其不要在验签前重排上游签名所覆盖的原始正文。
缓存和幂等键要使用哪一份数据
建议缓存键只由模型、稳定参数、已认证租户和经过规范化的语义正文构成；认证 Header、追踪 ID、时间戳不应进入缓存键。幂等键则应由客户端显式提供，中转站只负责记录其作用域、有效期和正文摘要，不能把“相似 JSON”自动当成同一笔写操作。对于工具调用、扣费或文件上传，请求相同也不等于可以重放。
Unicode 是最容易被漏掉的测试项
为名称、提示词和工具参数准备 NFC/NFD、全角符号、零宽字符、混合脚本三类样本。比较规范化前后的缓存命中、内容审核命中和审计检索结果；若业务需要保留原文，就只在比较视图中折叠，不要覆盖原始内容。还应限制不可见控制字符，避免日志展示内容和模型实际收到的内容不一致。
一套可执行的验收清单
- 相同语义、不同字段顺序的只读请求应命中同一缓存键；
- 更换租户或权限后必须得到不同缓存键和不同审计边界；
- 签名请求应使用文档规定的原始字节或规范化算法，不能混用；
null、空字符串、缺失字段应按上游语义分别回归；- 出现解析失败时，返回可定位的 4xx，不把半解析结果送到模型。
接入多家模型时，可在 top-api.cc 统一记录请求摘要、模型参数和回退链路，再按供应商兼容性选择规范化策略。这样既能减少无意义的缓存碎片，也不会为了“统一格式”破坏真实协议。
上线后的观测重点
观察规范化命中率、签名失败率、同一幂等键的正文冲突率，以及按 Unicode 类别划分的解析失败。任何指标突增都应保留原始请求样本的受控引用，并支持一键回退到仅透传模式。对开发团队而言，能解释“为何相同”比单纯追求缓存率更重要。
如果正在比较多个 AI API 入口，可先用 top-api.cc 的统一调用记录构造这类等价请求集，确认行为一致后再扩大流量。
Leave a Reply