Java接口的核心作用是定义行为契约，实现统一使用、自由替换与组合扩展；其不可替代性在于描述“能做什么”，支持多实现、无状态、高内聚，命名须为能力型形容词，方法应简单明确、避免实现细节，且需保障无感替换与向后兼容。
Java接口的核心作用是定义行为契约，让不同类在不关心彼此实现的前提下，能被统一使用、自由替换和组合扩展。
为什么必须用 interface 而不是抽象类？
关键区别不在语法，而在设计意图：接口描述「能做什么」，抽象类描述「是什么」。比如 Comparable、Runnable、Closeable 这些 JDK 标准接口，没有状态、不参与继承链，只声明能力——这正是接口不可替代的价值。
- 一个类只能
extends一个父类，但可以implements多个接口，这是实现“角色叠加”的唯一合法路径 - 接口中所有字段自动是
public static final，方法默认public abstract，强制你聚焦行为而非数据或流程控制 - Java 8+ 的
default方法不是为了偷懒补实现，而是为向后兼容——新增方法时，已有实现类不会编译失败
接口命名和方法设计最容易踩的坑
真实项目里，烂接口往往不是语法错，而是语义模糊或职责过载。比如把 UserManager 定义成接口，里面塞了 create()、sendEmail()、logAudit() ——这不是接口，这是上帝类草稿。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 接口名必须是形容词或能力名词：
Serializable、Cloneable、Drawable，而不是UserManager或OrderService - 单个接口只表达一个内聚能力；需要多个能力？就让类实现多个接口，而不是堆砌方法
- 避免在接口里暴露实现细节，例如
getCacheKey()或convertToDto()——这些属于具体实现策略，不该出现在契约里
怎么判断一个接口是否设计合理？
看它能不能被「无感替换」：把 new MySqlUserRepository() 换成 new RedisUserRepository()，只要都实现了 UserRepository 接口，上层业务代码一行都不用改，且逻辑不变——这才算合格。
立即学习“Java免费学习笔记（深入）”；
- 接口方法参数尽量用简单类型（
String、long、enum）或领域无关 DTO，别传HttpServletRequest或JdbcTemplate - 返回值避免
null，优先用Optional或明确的空对象（如EmptyList），否则调用方永远要加判空 - 接口一旦发布，就尽量别删方法、别改签名；想加功能？用
default方法，或者定义新接口（UserRepositoryV2是信号灯，说明旧接口已失控）
真正难的不是写 interface 关键字，而是在需求还没定死时，就预判出哪些行为该抽成契约、哪些该留给实现类自己决定。接口越早收敛，后期改起来越轻；拖到上线前才补接口，往往意味着契约已经混进一堆实现细节，再抽就只剩重写了。
