需求一开始听起来很简单：集团采购了一项企业数据服务，只有一把官方密钥，但好几家子公司的业务系统都要调用。最省事的做法是把密钥发给大家——这也是最危险的做法。
直接分发会出什么问题
成本不可控：谁都能调，月底才知道花了多少
重复花钱：A 公司昨天查过的企业，B 公司今天再查一遍，照样计费
无法追溯：出了问题不知道是哪家、哪个系统调用的
无法止损：密钥一旦泄露，只能整体更换，所有系统一起停
我的方案：密钥不出门
官方密钥只保存在中台，子公司拿到的是中台签发的 子密钥。子密钥可以单独启停、单独重置，泄露了只影响一家。
一次请求进来，先过风控，再读缓存：
子公司请求
→ 密钥校验 → IP 白名单 → 接口授权 → QPS 限流 → 每日配额
→ 读集团缓存
命中 → 直接返回，不消耗官方配额
未命中 → 如实返回“未命中”一个反直觉的决定
缓存未命中时，中台 不会 替子公司去调用官方接口。只有集团后台的查询、手动刷新和批量预热才会真正触达上游。
这样做牺牲了一点“即查即得”的体验，换来的是成本完全可预期：官方配额只由集团一侧消耗，子公司再怎么调用，都不会把预算打穿。配合批量预热，常用的企业数据会被提前沉淀下来。
几个值得提前想清楚的点
字段也要分权限：不同接入方绑定不同的字段包，同一个接口返回的字段范围不一样
配额要分层：子公司 QPS、子公司每日请求、集团每日配额、合同总量，四层各管各的
拦截也要留痕：被风控挡掉的请求同样写日志，否则排查时会少一半信息
回头看，这个产品真正的价值不在“转发请求”，而在把一件原本靠自觉的事，变成了可配置、可统计、可审计的事。