并发读查询不再被 429 拦截

并发发起参数相同的读查询时，其中一次会收到 429 请求太快了,请稍后再试。 该限制已解除，读接口可放心并发。同时新增 92302，把「重复提交」与「频率超限」 明确分开。

原因

主站有一道全局防重复提交的闸，按请求 URL 后缀判断是不是查询——/page、/list、 /detail 等自动放行，其余加锁。

开放平台的入口是泛化派发端点，URL 恒为 /v1/api/invoke（MCP 则是 /v1/mcp）， 从 URL 看不出背后调的是哪个接口，那份查询白名单永远匹配不上。于是同一个查询走 主站被放行、走开放平台却被当成写操作加了锁：

主站  POST /v1/customer/page   → 命中 /page，放行
开放  POST /v1/api/invoke      → 匹配不上，加锁 → 并发相同查询 429

现在的行为

判定依据改为接口注册表里的读写声明，不再猜 URL：

	并发相同请求	顺序相同请求
读接口	全部放行	全部放行
写接口	一次放行，其余 92302	全部放行

写接口的防重保留——参数完全相同的写请求在前一次尚未返回时重发会被拦下，这是 防止重复下单、重复入库这类问题的必要保护。

新增 92302

此前这类拒绝复用的是 429，与频率超限混在一起，集成方无从区分该退避还是该等待。 现在分开：

• 92301 请求过于频繁 —— 频率超限，退避后重试
• 92302 该请求正在处理中 —— 有参数相同的写请求未返回，等前一次返回即可，无需退避

判定依据是「凭证 + 接口编码 + 请求参数」三者全同，参数不同即视为不同请求。 详见错误码。

顺带

这类拒绝此前发生在调用审计之前，不留任何记录。现已补记，可在调用审计中查到。