扩展函数这题，答"String 的扩展方法是定义在 String 类上的方法"就掉分了——它根本不是方法。答出"编译后变成一个静态方法、接收者作为第一个参数"只够及格；再进一步能讲清静态决议、成员优先级、不能被多态调用，这题就有层次感了。这三点恰好也是实际写代码时最容易踩坑的地方。
先把结论放在前面：扩展函数是静态方法，编译后落在文件所在的类里（Kotlin 允许通过 @file:JvmName 改名），第一个参数是接收者。调用时按接收者的静态类型决议——Animal 类型的引用调用的扩展，编译进去的就是 Animal 那个版本；扩展函数不参与多态，子类重写同名成员也不会影响扩展的调用。 三条规则合起来推出核心纪律：扩展函数不能访问 private 成员、不能有 open、不能被反射按类型动态选择。
机制拆解
看声明与编译。fun Animal.speak(): String = "..." 编译成文件类里的 public static String speak(Animal $this)。调用 dog.speak() 编译成 FileClass.speak(dog)。 这一条解释了三个现象：①扩展能"加方法"是因为它只是一个函数，参数名叫什么无关紧要；②private 成员访问不到，是因为静态函数在类的外部，Java 的访问控制不认"同文件"这种 Kotlin 约定；③无法 open/override，因为它不是虚方法。
第二条规则是成员优先。dog.addSkill() 如果 Animal 里已有同名成员函数，编译器会报"成员覆盖了扩展"的提示并采用成员版本；属性同理（扩展属性与成员属性同名时成员胜出）。这带来一个真实的坑：给第三方类加扩展时，如果那个类后来自己加了同名成员，代码行为会静默改变——从你的实现变成库的实现，且不报错。
第三条是静态决议。这是本篇最核心也最有价值的一条。假设 Animal 有一个扩展 Animal.speak()、Dog 有一个扩展 Dog.speak()，val a: Animal = Dog(); a.speak() 调用的是 Animal 版本。因为编译器看的是变量声明的类型 Animal，直接静态调用 FileClass.speak(a)。 而 Dog 有成员函数 speak() 时，a.speak() 仍然调扩展（成员函数是动态分派的，编译成 invokevirtual；扩展是静态的，编译成 invokestatic），两者不会混淆。
这些坑的正确绕法
最常见的坑是以为扩展函数参与多态，父类引用调用扩展执行的是父类版本，语义误判。 表现是给一个基类写了扩展方法后，想通过子类重写行为来实现"不同的类表现不同"，但无论如何都拿到基类版本；或者反过来，明明想调基类版本却因为子类里恰好有同名成员而拿到了子类的。 修法有两条：①需要多态就别用扩展，改成基类的成员方法（可以是 open）；②需要按类型分派就用显式的重载（为每个具体类型各写一个扩展，靠静态类型选择），这正是 Kotlin 的风格——用静态分发换简洁，而不是假装有多态。
其次是扩展函数里访问不到 private/protected 成员，绕路去用反射或 internal。 表现是想给某个第三方或自家类做增强时发现访问不了它的私有字段，于是改用反射，读写性能与稳定性都下降。 修法是：需要访问内部状态，说明这个操作属于该类的职责，应该在类内部加成员方法；如果只是需要一点上下文，用 internal 修饰符或把必要参数作为扩展函数的显式参数传进来。
还有一个更隐蔽的坑：同名扩展在文件间冲突，IDE 报"引用不明确"或静默用错。 表现是同一个调用在不同机器上解析到不同实现（取决于 import 顺序与是否显式指定包），或者突然编译不过。 对策是给扩展函数显式指定包名调用（com.a.stringUtil(x) 形式在 Kotlin 里写作 with(com.a) { x.stringUtil() }，或用别名 import），并避免在不同包里放同名扩展。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
// 1) 编译形态：扩展不是方法，是静态函数
fun Animal.speak(): String = "${this.name} 叫" // -> static String speak(Animal)
// fun String.shout(): String = uppercase() + "!" // -> static String shout(String)
// 2) 静态决议：父类引用调用的是父类版本的扩展
fun Animal.describe(): String = "Animal: $name"
fun Dog.describe(): String = "Dog: ${breed}" // 另一个扩展
val a: Animal = Dog("柯基")
a.describe() // "Animal: ..." ← 按声明类型 Animal 静态决议
(a as Dog).describe() // "Dog: ..." ← 显式转类型后才走 Dog 的扩展
// 3) 成员优先于扩展：成员是虚方法，会动态分派
open class Animal2 {
open fun tag(): String = "animal-member" }
class Dog2 : Animal2() {
override fun tag(): String = "dog-member" }
fun Animal2.tagExt(): String = "ext" // 不会被调用（同名成员存在时）
Dog2().tag() // "dog-member"，成员动态分派
Dog2().tagExt() // "ext"，扩展静态调用
// 4) 扩展属性同样受成员优先规则约束
val Animal3.size: Int get() = 1
// 若 Animal3 里已有 val size，扩展属性会被忽略（成员胜出）
// 5) 扩展访问不到 private/protected
class Repo(private val dao: Dao) {
private fun secret() = 42
}
fun Repo.debug(): String = "..." // 写不了 secret()，访问不到
// 修法：把需要的能力做成成员，或把参数显式传进来
fun Repo.describe(count: Int) = "$count 条" // 参数由调用方提供上下文
// 6) 常用扩展的真实价值：让链式调用更自然
fun String.isBlankOrNull(): Boolean = isNullOrBlank()
fun List<Item>.filterValid(): List<Item> = filter {
it.valid }
这段代码值得盯三处：第一处，第 2 段的两条 describe 扩展 + 父类引用调用，直接演示"静态决议"——这是本篇最核心的知识点；第二处，第 3 段展示"成员优先 + 成员动态分派"，说明为什么 tag() 拿到的是子类的成员实现而 tagExt() 走的是扩展；第三处，第 5 段的注释说明访问不到私有成员该怎么绕。
这题在面试里怎么问、怎么答
"扩展函数能重写吗？"答：不能，因为它不是虚方法。要实现"不同类型不同行为"，要么给基类加 open 成员方法，要么为每个具体类型各写一个扩展（靠静态类型选择），要么用带策略参数的通用函数。Kotlin 选择让扩展保持简单，把多态交给成员。
"扩展函数能访问 private 吗？为什么？"答：不能。编译后扩展是文件类里的静态方法，处于目标类的外部；Kotlin 的 private 是类级可见（同一个文件内的顶层私有除外），internal 是模块级可见，都不覆盖"外部类访问"这一层。
"扩展属性是怎么实现的？"答：val Animal.name: String get() = "..." 编译成 public static String getName(Animal)，是函数不是字段——每次访问都走方法调用，没有存储。
"泛型接收者的扩展怎么写？有什么用？"答：fun <T> List<T>.secondOrNull(): T? = getOrNull(1)。泛型接收者让扩展可复用（对所有 List<T> 生效），泛型约束保证"接收者必须含某成员"（fun <T : CharSequence> T.trimOrNull()），这让扩展既通用又安全。
"使用中遇到过什么问题？"案例一：给一个基类写了扩展方法，项目里出现"某些界面行为一致"的诡异问题；定位到子类的类型被声明成基类，静态决议走了基类版本；修复为显式按具体类型调用或改成成员方法。案例二：给第三方类写的扩展在对方发版后突然不生效了；定位到库新增了同名成员，成员优先规则导致调用被改道。
再补一个工程上值得讲清的一点：扩展函数最实用的价值是"给外部类加语义"，但要守住两条线。 ①只扩展语义，不扩展状态——扩展函数应该是纯函数式的（输入决定输出），一旦它需要访问内部可变状态，语义就开始模糊了；②放在明确的包里并起有辨识度的名字——String 的扩展叫 isBlankOrNull 好，叫 toIntOrZero 也能用但容易与其他库冲突。 Android 项目里常见的正确用法是：给 Bundle 加 getStringOrDefault、给 View 加 setVisible、给 Context 加 dpToPx ——这些都在语义层而不是实现层，扩展出去也说得通。反面是把业务逻辑扩展到系统类上（在 String 上加 isValidUserCode），那是污染，不是增强。
给正在准备面试的你
把这题画成一张"三步判定"流程图：起点是"调用 x.foo()"，第一步查成员优先——静态类型里有没有同名成员？有就走成员（虚方法，动态分派）；没有进入第二步。第二步查静态决议——按静态类型找对应的扩展版本，编译成 invokestatic；找到就调用，找不到编译报错。图旁标一句"没有虚函数表参与，所以没有运行时多态"。 图下方画一行"因此不能做的事"：访问 private、open/override、被反射按类型动态选择。这张图能一句话回答"扩展到底是不是方法"这个问题。
再补工程案例与踩坑——应用落点是给项目里现有的扩展函数做一次 review：确认没有访问内部状态（把需要状态的改成成员方法）、确认没有同名冲突（补显式包名或别名）、确认没有试图用扩展实现多态（改成 open 成员），并给系统类的扩展补上明确的命名。
复习时别孤立刷题：object 与 companion object——扩展函数编译后是文件类里的静态方法，和 object 的静态成员在编译产物层面是同一类东西。
划两句重点：扩展编译成静态方法，接收者是第一个参数；成员优先于扩展；按静态类型决议、不参与多态；访问不到 private、open/override 都不行；扩展只加语义不加状态。
下一篇聊顶层函数与属性：为什么不再需要 Utils 类——沿着今天这条主线继续往前走。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：object-与-companion-object：Kotlin-里的单例
下一篇预告：顶层函数与属性：为什么不再需要-Utils-类
有任何问题欢迎在评论区留言交流。
