接口参数能避免调用方被实现细节绑架，如用List代替ArrayList可兼容多种实现，提升扩展性与可测性，且不牺牲类型安全和性能。
接口参数能避免调用方被实现细节绑架
当你把 ArrayList 或 HashMap 直接写进方法签名，调用方就只能传这个具体类型——哪怕它手头只有 LinkedList 或 TreeMap，也得先转成前者。这不是设计，是锁死。
换成接口后，比如用 List 代替 ArrayList，调用方传 Arrays.asList()、CopyOnWriteArrayList、甚至自己写的轻量 List 实现都合法。关键不是“能用”，而是“不用改你的代码就能适配新需求”。
- 常见错误现象：
IllegalArgumentException: expected ArrayList, got LinkedList—— 实际上这根本不是运行时错误，而是编译失败，因为方法签名硬编码了具体类 - 使用场景：工具类方法（如
StringUtils.join(List<string>)</string>）、框架回调（如 Spring 的BeanFactoryPostProcessor.postProcessBeanFactory(ConfigurableListableBeanFactory)） - 参数差异：
void process(List<string> data)</string>比void process(ArrayList<string> data)</string>多支持至少 5 种 JDK 内置实现，还不算 Guava、Apache Commons 的扩展类
泛型接口参数让类型安全不打折扣
有人担心用 List 会丢类型信息，其实不会。Java 泛型擦除发生在运行时，但编译期检查照常——process(List<integer>)</integer> 和 process(List<string>)</string> 是两个完全不同的方法签名。
真正要小心的是通配符滥用。比如 process(List extends Number>) 看似灵活，但你在方法里没法往里面 add 任何东西（除了 null），而 process(List<number>)</number> 就没这限制。
- 容易踩的坑：
List>是“未知类型列表”，连get(0)返回的都是Object，基本等于放弃类型约束 - 性能影响：无。接口引用和具体类引用在字节码层面都是对象引用，JVM 不会因为用了
Collection就多一次虚方法查表 - 兼容性影响：Java 5+ 全支持；Android minSdk 21+ 也没问题；老版本（如 Java 1.4）压根没泛型，谈不上兼容
测试和 mock 成本直线下降
如果方法参数是 HttpClient（某个具体 HTTP 客户端类），你测的时候就得启动真实服务或写一堆反射绕过构造；换成 HttpClientInterface 或标准的 CloseableHttpClient（Apache HttpComponents 的接口），直接 new 个匿名内部类或用 Mockito mock 就完事。
Spring 生态里更明显：所有 Repository 接口、Service 接口，本质都是为解耦和可测服务的。你见过哪个 Spring Boot 测试类去 new JpaRepositoryImplementation 吗？没有。
- 常见错误现象：单元测试里出现
new RedisTemplate()，然后卡在连接池初始化失败 —— 因为参数类型绑死了具体实现 - 使用场景：需要隔离外部依赖的测试（数据库、HTTP、消息队列）、快速验证业务逻辑分支
- 实操建议：优先用 JDK 或主流库已有的接口（如
java.util.function.Predicate、javax.sql.DataSource），别急着自己定义新接口，除非真有行为抽象必要
继承体系越深，接口参数越不可替代
假设你有个 PaymentService，它依赖一个 PaymentGateway。如果参数类型是 AlipayGateway，那微信支付、PayPal、Stripe 都得各自重写一个方法；换成 PaymentGateway 接口，新增渠道只要实现接口、注入容器就行，原有调用代码一行不动。
这不是“面向接口编程”的教条，是每天都在发生的修改成本问题：改一个参数类型，可能触发十几个模块编译失败；而改一个接口方法，只影响实现类和少数明确依赖它的测试。
- 容易踩的坑：把接口定义得太宽，比如让
PaymentGateway同时包含refund()、preAuth()、capture()，结果某些网关根本不支持预授权，被迫抛UnsupportedOperationException - 实操建议：按能力契约拆接口（
RefundableGateway、PreAuthorizableGateway），而不是堆砌大而全的接口 - 性能 / 兼容性影响：接口多态调用比具体类调用略慢（纳秒级），但现代 JVM 的内联优化基本抹平这点差异；接口本身不带状态，也不影响序列化兼容性
最常被忽略的一点：接口参数不是为了“看起来更抽象”，而是为了把变化关进盒子。只要接口定义稳定，外面怎么换实现，都不会波及到使用它的地方。而那个盒子的边界，就是参数类型声明的位置。
