默认方法不是补丁接口的快捷键，不应充当通用逻辑容器或模板方法，须避免依赖注入、跨模块耦合、多接口冲突及抽象调用风险，仅适用于无依赖、幂等、轻量的辅助行为。
默认方法不是“补丁接口”的快捷键，用错地方反而会让代码更难维护、更易出错。
别把默认方法当工具类用
常见误区是把默认方法写成通用逻辑容器，比如在接口里调用 Spring Bean、做日志记录、甚至封装 HTTP 请求。这看似省事，实则破坏了接口的契约本质——接口描述“做什么”，不该决定“怎么做”或“依赖什么”。
- 默认方法无法访问实现类的实例字段，只能靠传参或静态上下文（如 BeanAccessor），后者极易引发空指针或上下文未初始化问题
- 一旦接口被多个模块复用，其中嵌入的 Spring 依赖会强制所有使用者引入对应 Bean，耦合度飙升
- 单元测试时难以 mock，默认方法里的外部调用常导致测试失败或绕过真实逻辑
避免覆盖已有行为却不自知
给已广泛使用的接口新增默认方法，哪怕逻辑看似无害，也可能悄悄改变行为。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 如果某个实现类原本继承了父类的同名方法，而你新加的默认方法签名一致，它会被父类方法直接屏蔽——开发者根本不会察觉，但语义已变
- 若实现类恰好定义了同名私有方法或默认方法（Java 9+），编译器不报错，但运行时调用路径可能不符合预期
- 建议：加默认方法前，先 grep 所有实现类源码，确认无同名方法；再跑全量回归测试，尤其关注未重写该方法的类
多接口冲突不是语法错误，而是设计信号
编译器报“must override”不是麻烦，是在提醒你：两个接口对同一行为给出了不同默认解释——这说明它们的职责可能重叠或抽象层级不一致。
立即学习“Java免费学习笔记（深入）”；
- 不要机械地选 A.super.xxx() 或 B.super.xxx() 敷衍了事，先问：这两个接口真该被同一个类同时实现吗？
- 更健康的解法往往是提取公共行为到新接口，或用组合代替多重实现（例如把 Alarm 功能抽成 AlarmProvider 字段）
- 若必须保留多实现，重写方法里应明确表达业务意图，而不是简单转发，比如：
log("Car honking via vehicle protocol")
默认方法 ≠ 模板方法，慎用抽象调用
在默认方法里调用未实现的抽象方法，表面看是模板模式，实际埋下执行风险。
- 如果抽象方法返回 null 或抛异常，整个默认流程就断了，且调用栈难以追溯
- Java 不支持接口内强制非空约束，也无法做参数校验，可靠性远低于普通类中的模板方法
- 真正需要模板逻辑时，优先考虑抽象类；接口默认方法更适合提供无依赖、幂等、轻量的辅助行为（如
isEmpty()基于size()的推导）
