扩展函数本质是编译器生成的静态方法，中缀函数仅是一种调用语法糖；二者无本质性能差异，实际开销完全取决于底层实现而非修饰关键字。
扩展函数本质是编译器生成的静态方法，中缀函数仅是一种调用语法糖；二者无本质性能差异，实际开销完全取决于底层实现而非修饰关键字。
在 Kotlin 开发实践中，开发者常对扩展函数（Extension Function）和中缀函数（Infix Function）的性能产生疑问：“它们谁更快？”——但这个问题本身存在概念混淆。扩展函数与中缀函数并非同一维度的技术特性：前者是功能扩展机制，后者是调用语法约定。二者可正交组合使用，性能表现也应分开理解。
✅ 扩展函数：零运行时开销的“静态代理”
扩展函数在编译期被转换为静态方法（JVM 上为 static 方法），接收者对象作为首个隐式参数传入。例如：
fun String.isLongerThan(length: Int): Boolean = this.length > length
等价于 Java 中的静态工具方法：
public static boolean isLongerThan(String $receiver, int length) {
return $receiver.length() > length;
}✅ 性能特征：
- 无对象创建、无虚方法调用、无装箱/拆箱（基础类型参数除外）；
- 调用开销 ≈ 普通静态方法，与
StringUtils.lengthGreaterThan(str, 10)完全一致； - 不修改原类，不触发反射或动态代理，纯编译期合成。
✅ 中缀函数：纯粹的语法糖，无额外成本
中缀函数不是独立函数类型，而是带 infix 修饰符的普通函数（成员或扩展均可），仅影响调用写法：
infix fun String.toPair(other: String): Pair<String, String> = this to other
// 调用方式（两种等价）：
"key" to "value" // 中缀语法（推荐 DSL 场景）
"key".toPair("value") // 普通点调用（等效字节码）✅ 性能特征：
- 编译后生成的字节码与非
infix版本完全相同； -
infix关键字仅参与编译期语法解析，不生成任何额外指令或运行时检查； - 空格分隔只是 Kotlin 编译器的词法约定，不涉及字符串解析或动态分派。
⚠️ 注意事项与最佳实践
-
勿为性能选型：是否使用
infix应基于可读性与领域语义（如5 seconds,user owns permission），而非性能假设； -
避免滥用扩展：过度定义全局扩展函数（尤其
Any.或String.）会污染命名空间，增加 IDE 分析负担——这是工程维护问题，非性能问题； -
优先复用标准库：
to,shl,rangeTo等内置中缀函数已高度优化，无需重复造轮子； - 性能敏感场景实测为准：若疑虑特定扩展/中缀调用有异常开销，应通过 JMH 基准测试验证，而非依赖直觉。
✅ 总结
| 维度 | 扩展函数 | 中缀函数 |
|---|---|---|
| 本质 | 编译期静态方法代理 | 函数声明修饰符（影响调用语法） |
| 性能开销 | ≈ 静态方法调用 | ≈ 其对应非 infix 版本 |
| 可组合性 | 可与 infix、operator 等共用 |
必须依附于扩展或成员函数存在 |
| 决策依据 | 是否需为类型添加便捷能力 | 是否需提升二元操作的自然语言表达力 |
因此，回答最初的问题：不存在“扩展函数 vs 中缀函数”的性能比较——就像比较“螺丝刀”和“红颜色”：一个解决功能扩展问题，一个解决代码可读性问题。真正影响性能的是函数体逻辑（如是否触发 GC、是否含复杂计算），而非 fun 前是否有 infix 或接收者类型声明。写出清晰、正确、可维护的代码，永远比微优化语法修饰符更重要。
