使用适配器模式有哪些常见误区？
简化版
适配器模式常见误区包括：把适配器写成业务大杂烩、只转换方法名不校准业务语义、适配层泄露第三方模型、过度适配导致调用链混乱、异常和错误码转换不统一，以及本该重构接口却一直靠适配器补洞。
详细版
常见问题主要有：
- 适配器承担太多业务逻辑；
- 只看接口形态，不看业务语义；
- 第三方请求对象和异常类型泄露到业务层；
- 多层适配器叠加，调用链不清晰；
- 返回值、错误码、异常没有统一转换；
- 适配器命名和边界混乱；
- 把适配器当成接口设计不合理的长期补丁；
- 忽略性能和资源管理；
- 类适配器滥用继承，导致耦合过强；
- 简单场景过度设计。
面试时可以强调：适配器应该是边界层的接口转换器，不应该成为业务规则中心。好的适配器薄而清晰，输入输出稳定，能隔离外部变化。
完整版教学
一、误区一：适配器变成业务大杂烩
适配器应该负责接口转换，比如参数转换、返回值转换、异常转换。
但有些项目会把大量业务规则放进适配器：
适配器里查数据库
适配器里算价格
适配器里控制状态流转
适配器里发业务事件这样适配器就不再是适配层，而变成隐藏的业务服务。
业务规则应该放在应用服务、领域服务或明确的业务模块中，适配器只负责连接边界。
二、误区二：只看方法名，不看语义
两个接口方法名相似，不代表语义一致。
比如：
cancelOrder
closeTrade
refundOrder
reversePayment这些词可能在不同系统里代表完全不同的状态变化。
如果适配器只是简单映射：
cancelOrder() -> closeTrade()可能导致库存、优惠券、支付状态都不一致。
适配前必须确认业务语义、幂等规则、失败处理和副作用。
三、误区三：第三方模型泄露到业务层
适配器存在的目的之一是隔离外部依赖。
错误做法是业务层方法里到处出现：
AliyunSmsRequest
WxPayResponse
ThirdPartyException这说明适配层没有把外部模型挡住。
更好的做法是业务层只使用内部模型：
SmsCommand
SmsResult
PayCommand
PayResult第三方对象只出现在适配器内部。
四、误区四：错误码和异常转换不统一
第三方系统的错误码和异常类型往往各不相同。
适配器需要把它们转换成内部统一语义：
- 外部超时 -> 内部可重试异常；
- 外部参数错误 -> 内部业务失败；
- 外部限流 -> 内部限流错误码；
- 外部系统异常 -> 内部系统异常。
如果每个适配器随意返回字符串或直接抛第三方异常，业务层会越来越难处理。
五、误区五：适配层泄露过多细节
适配器的接口不应该设计成第三方 SDK 的翻版。
比如内部接口这样设计就很危险：
AliyunResponse send(AliyunRequest request);这表面上有接口，实际仍然绑定阿里云。
内部接口应该表达本系统稳定需求，而不是某个供应商的形状。
六、误区六：把适配器当成长期补丁
适配器适合兼容和迁移，但如果系统长期靠一堆适配器修修补补，说明底层抽象可能已经不健康。
当适配器越来越厚、越来越多、越来越难命名时，要考虑：
- 是否需要统一接口标准；
- 是否需要重构领域模型；
- 是否需要拆分边界上下文；
- 是否需要淘汰旧接口。
适配器能过渡，不应该永远替代合理抽象。
七、误区七：忽略资源和性能
适配器里可能会创建客户端、转换大对象、做序列化和网络调用。
如果每次调用都新建重量级对象，性能会有问题。
适配器应该注意：
- 复用线程安全客户端；
- 不重复做昂贵转换；
- 明确超时和重试；
- 避免吞异常；
- 记录必要日志。
八、误区八：简单场景强行套模式
如果只是一个局部方法参数名称不同，用一个私有转换方法就能解决，没必要上升为完整适配器类。
设计模式服务于复杂度。当接口差异会扩散、外部变化需要隔离、多个实现需要统一时，再引入适配器更合适。
九、用契约样例防止“能调通但语义错”
汇率接口返回 1.075，若用 double 再保留 2 位得到 1.08；金额 10000 元会产生约 50 元差异，金融适配应使用 BigDecimal 和明确舍入。
contract samples -> map -> boundary/precision tests -> error mapping -> metrics适配器的验收标准不是“调用成功”，而是 Target 的业务语义在转换前后保持成立。参数、单位、时区、精度、空值、错误码和资源所有权都应逐项形成契约样例，否则最危险的错误会以“成功响应”的形式潜伏。
十、语义边界与契约样例验证
| 检查维度 | 应确认的内容 |
|---|---|
| 机制正确性 | 适配器最危险的错误不是编译失败，而是静默单位、精度或错误语义偏差。 |
| 适用边界 | 适配层要记录供应商请求 id 和错误码，但日志必须脱敏；重试还要区分查询与非幂等写操作。 |
| 测试证据 | 使用边界值和故障桩验证错误码归并、超时、重试幂等、日志脱敏与资源释放 |
| 工程代价 | 重点统计字段映射与对象分配成本、外部模型变更影响面，以及多层版本适配造成的认知债务 |
易错点：适配器最危险的错误不是编译失败，而是静默单位、精度或错误语义偏差。
十一、常见误区与追问
- 误区：所有外部异常都转换成一个“调用失败”最简单。 过度归并会丢失可重试、参数错误和业务拒绝的差异，应建立稳定但有区分度的错误模型。
- 误区：适配器只需要让方法签名能够编译。 真正的适配还包括单位、时区、错误码、空值、资源释放和幂等语义；签名一致不代表行为兼容。
- 追问：如何发现第三方模型已经泄漏？ 搜索业务层对 SDK 类型、错误码和字段名的依赖；这些依赖应收敛到适配边界。
- 追问：适配器应该放在哪一层？ 通常放在系统边界或防腐层，让业务层只依赖 Target，避免第三方模型和异常向内扩散。
- 追问：适配器测试为什么需要契约样例？ 因为类型相同仍可能单位、精度或错误语义不同；契约样例能证明转换后的行为而不只是编译通过。
十二、加强记忆
适配器的坑可以记成“别藏业务、别糊语义、别漏外部模型、别乱转异常、别层层套娃”。好的适配器应该薄、清晰、边界明确，把外部差异挡在系统边缘；如果适配器越来越厚，通常是在提醒你该重新设计接口或领域模型了。