中间件封装到底该封多深：薄薄一层透传，还是厚一层把坑都填平？

背景

每次封装一个中间件（MQ 客户端 / 缓存 / RPC / 配置中心），都绕不开同一个问题：这层壳到底该多厚。

打个比方：中间件封装就像给一台发动机装"操作台"。薄操作台，基本就是把油门、挡位原样引出来，司机（业务方）想怎么开怎么开；厚操作台，则把自动换挡、巡航、防抖、故障自诊断全藏进面板里，司机只认"我要去哪"。两种操作台我都见过，而且两种都翻过车：

• 薄到散架：只统一了入口和日志，重试、超时、降级全靠业务方自己写，结果十个服务写了十个版本的重试，逻辑散落在各处，出问题时没人说得清"到底重试了几次、间隔多少"。
• 厚到藏死：把序列化、重试、降级、连接管理全吞进去，业务方只用几个"业务语义"方法。平时挺爽，可一旦碰到边界 case（比如某类消息必须不重试、某种超时不能降级），没人看得懂底层在干嘛，排障只能靠翻源码 + 猜。

几种常见做法（分歧点）

1. 透传薄壳：只统一入口与日志，行为尽量贴近原生，"想怎么用怎么用"，把控制权全交给业务方。
2. 厚封装：重试 / 超时 / 降级 / 幂等 / 监控全内置，业务方只调业务语义方法，默认行为"开箱即用"。
3. 分层：核心调用路径保持薄（贴近原生、可解释），横切关注点（日志 / 指标 / trace）由框架统一注入。
4. 策略外置：把重试、超时、降级做成可插拔策略，默认给一套，允许业务方按需覆盖。

我的倾向与理由

我偏 3 + 4 组合：核心路径薄而透明，横切能力统一注入，行为参数策略外置、可覆盖。

核心就一条：可维护性最大的敌人，是"看不见的默认行为"。 厚封装一旦把语义藏太深，出事时排障成本极高，而且"默认帮你做了 X"这件事，往往只有写封装的人知道；而薄到没有横切能力，又会把本该统一的逻辑散给每个业务方，最后"各写各的"，规范根本落不了地。

所以我给团队的准则是：默认行为要"少而透明"，高级行为要"可覆盖、可观测"。 凡是默认替你做的决定，要么能一行关掉，要么能在日志/指标里看到它做了——两条至少占一条，否则别默认开。

想听大家在什么场景下怎么选

• 你手头的中间件封装是偏薄还是偏厚？判断"够不够厚"的准则是什么（有文档还是拍脑袋）？
• 重试 / 降级这类逻辑，你放中间件里还是放业务里？边界怎么划？
• 踩过"封装太厚 → 底层语义被藏死、排不了障"或"封装太薄 → 业务各写各的"的坑吗？最后怎么收的？
• 策略外置（可插拔）你们真落地得动吗，还是大家最后还是在配置文件里各配各的、等于没外置？

欢迎把你团队的"封装厚度"清单和踩坑贴出来，咱们对着聊。