服务间调用该不该默认开重试？责任该放在哪一层

背景 我最近在帮一个组定「服务间调用的公共规范」，走到「默认要不要开重试」这一步，组内直接吵起来了。这个点平时大家各自服务里都有一套，但没人愿意把它写成团队级默认值——因为它一旦写成默认，就等于替所有调用方做了决定。

三种常见做法（也是三种立场）

1. 默认开、透明可用：认为「下游抖一下就该自动重试」，重试下沉到 HTTP client / 网关 / 中间件层，业务无感。好处是省心，坏处是——非幂等写会被重试放大成重复扣款/重复下单，这是我在一次 Kafka 事务单里见过最典型的事故形态。
2. 默认关、显式声明：认为重试是「语义决策」，必须调用方自己声明，且声明时强制带上幂等键。好处是可控，坏处是每处调用都要记得配，容易漏，漏了就是裸奔。
3. 分层：只读/幂等接口默认开，写接口默认关 + 强制幂等键，由中间件按「注解/标签」区分。好处是兼顾，坏处是这套「怎么判幂等」的元数据本身要有人维护。

我的倾向与理由 我站 3（分层默认 + 幂等前置）。理由有三：

• 幂等是重试的前提，不是重试的补丁。顺序反了就是把「抖动」换成「重复」，事故等级反而升了。
• 「谁调用谁声明」听起来干净，但 3 年里我看到的漏配率不低；把默认值做成「安全侧」（写默认关），比指望每个人记得开，成本低得多。
• 把「是否幂等」沉淀成接口级元数据（注解/契约字段），一次声明多处复用，比每处调用手写重试参数可维护得多——这也是我写中间件最看重的：默认值应该是「可预测」的。

想听大家 你们现在团队/项目里，服务间调用的重试默认是开还是关？

• 幂等读接口和写接口，你们会做区分吗？靠什么区分（注解？路由？还是干脆不区分）？
• 你们有没有踩过「默认开重试 → 非幂等写被放大」的坑？事故长什么样？
• 如果让你定团队默认值，你会把「重试责任」放在哪一层：client 库 / 网关 / 框架拦截器？为什么？

欢迎贴你们的具体配置或踩坑记录，我这边可以补一份「幂等前置 + 分层默认」的落地清单。