这个坑值得记一笔。前端同事把 Anthropic key 写进了打包后的 JS，上线两天控制台用量飙到平时的四十倍，来源 IP 分散在多个地区。
刚开始盯着「没有限制来源域名，第三方站点也能直接调用」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。key 随前端包一起下发，任何人都能从源码里读到；额度没有按用户维度设上限，被刷时没有任何闸门；旧 key 泄露后没有立刻吊销，继续在跑。
立刻吊销并新建专用 key
curl -sS -X POST https://api.anthropic.com/v1/api_keys -H "x-api-key: $ADMIN_KEY" -H "anthropic-version: 2023-06-01" -d '{"name":"server-only"}'然后把调用挪到后端，前端只调自己的接口
grep -rn 'sk-ant-' ./dist | head接着按用户维度做配额，超限返回 429
python -c "print('redis incr with expire per user')"给后端出口固定 IP 便于审计
curl -sS https://api.ipify.org怎么算真的好了，看的是同一批现象。打包产物里再也搜不到 sk-ant 开头的字符串，前端请求只打到自家域名，异常时段用量回落到基线。
这里还有个坑。模型 key 与普通业务密钥不同，泄露后损失按 token 计费直接体现，前端绝对不能持有，这条没有折中方案。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。