函数类型是 Kotlin 里"接口的替代品"——() -> Unit 比 interface Callback { fun onDone() } 短得多，而且能享受函数类型带来的语言特性（泛型、型变、空安全、默认值）。typealias 则解决另一个痛点：(User) -> Boolean 这类签名在项目里反复出现，长且难读。两者一起答，正是"用 Kotlin 的语言特性而不是绕着写"的信号。
先把结论放在前面：函数类型 FunctionN<P1..Pn, R> 的本质是接口——() -> Unit 对应 Function0<Unit>、(Int) -> String 对应 Function1<Int, String>，都有 invoke 方法。所以函数类型可以做变量、可以传参、可以返回（函数类型的字段不带 invoke 括号才是"函数引用"，带括号就是调用）。typealias 是纯编译期别名，展开后没有任何类型检查加成——它只改善可读性，不改变类型系统。这两条边界是本篇的核心：函数类型有语言级能力，typealias 没有。
机制拆解
先看函数类型的实现。(Int) -> String 编译成一个实现 Function1<Int, String> 的接口，方法名是 invoke。这意味着：
val f: (Int) -> String = { it.toString() }—— 赋值的是 Lambda 对象f(1)编译成f.invoke(1)—— 所以函数类型变量调用时可以带括号val g = ::compute——::引用（方法引用/属性引用/构造函数引用），此时g是函数类型的值，g(1)才是调用；f::invoke取的是它 invoke 方法的引用
三个引用形式要分清：::foo（顶层/成员函数）、Type::method（成员方法）、String::length（属性引用）、::Person（构造函数引用）。它们都是 KFunction 的实例，不是被调用的结果。String::length 的类型是 KProperty0<String, Int>，调用是 p.get()；而作为扩展接收者使用时 x::length 传给函数可以当 () -> Int。
typealias 的机制更简单：它在编译期被直接替换成真实类型。typealias Json = String 之后 fun parse(j: Json) 在字节码里就是 fun parse(j: String)。没有运行时痕迹，没有包装类。 所以 typealias 的收益是纯可读性的——把 (SuspendResult<User, Error>) -> Unit 写成 typealias UserCallback = (Result<User>) -> Unit 后，签名瞬间可读。
Kotlin 里还有两个相关特性值得一起讲：函数类型的型变是固定的（(in T) -> out R），因为 T 在参数位（逆变）、R 在返回位（协变），这与上一讲的型变规则一致；以及带接收者的函数类型 T.() -> R，它是 apply/with 这类作用域函数的参数类型。
这些坑的正确绕法
最常见的坑是 typealias 只是别名，两个业务同名回调互换传参编译器不报错，语义靠评审。 表现是定义了两份 typealias Callback = (Result<User>) -> Unit（分别在 user/ 与 order/ 包下），某个工具函数接受 user.Callback，结果被误传了 order.Callback——因为别名展开后都是同一个函数类型，编译器无法区分。修法有三条：①同名但语义不同的回调用不同的函数类型（(User) -> Unit vs (Order) -> Unit），哪怕长度一样也比混淆好；②给不同语义的回调定义不同的接口（真正名义上的类型隔离）；③在别名声明处写 KDoc 说明这个回调属于哪个业务，并把它放在与业务强相关的包里。判断标准是：如果两个回调"不能互换但类型相同"，就该用接口而不是 typealias。
其次是函数类型与 Java 互操作时，可空性丢失导致空指针。 表现是 Kotlin 声明的回调参数是 (String) -> Unit（非空），Java 侧传的实现方法参数声明成 String 平台类型，传 null 进来；Kotlin 侧生成的方法里没有 null 检查，访问时抛 NullPointerException（而不是有信息量的 IllegalArgumentException）。修法：跨语言边界的回调参数显式写成可空（(String?) -> Unit），或在 Kotlin 侧的方法里加 requireNotNull。Android 上这在第三方 SDK 提供的回调里尤其常见。
还有一个更隐蔽的坑：:: 引用在成员函数上拿的是"未绑定的"，传出去后失去实例上下文。 表现是 class A { fun handle(x: Int) {...}; fun register() { list.map(::handle) } }——::handle 是未绑定引用，调用时需要两个参数（接收者 + 实际参数），直接传进 map 会类型不匹配；写成 list.map { handle(it) } 才对。修法：成员函数用 lambda 显式调接收者，方法引用只在顶层函数或已绑定时（a::handle）使用。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
// 1) 函数类型就是接口：有 invoke
val f: (Int) -> String = {
"v$it" }
val r = f(1) // 编译成 f.invoke(1)
val ref = f::invoke // 引用 invoke 方法
val topLevel = ::compute // 顶层函数引用：KFunction2<Int, Int, Int>
val bound = obj::compute // 已绑定：只剩一个参数
val ctor = ::Person // 构造函数引用
val prop = Person::name // KProperty1<Person, String>
// 2) typealias：纯编译期别名，字节码里就是原类型
typealias UserId = String
typealias UserCallback = (Result<User>) -> Unit
typealias Parser<T> = (String) -> T
fun parse(j: UserId): User? = null // 展开为 (String) -> User
fun onDone(cb: UserCallback) {
cb(Result.success(User(1, "a"))) }
// 3) 别名的边界：同名不同义时用接口才安全
typealias OrderCallback = (Result<Order>) -> Unit
interface UserClickListener {
fun onClick(user: User) } // 真正名义隔离
// fun wrong(cb: UserCallback) = wrong(orderCb) // 若两者别名相同，编译不报错
// 4) 带接收者的函数类型：作用域函数的参数
inline fun <T> T.applyIt(block: T.() -> Unit): T {
block(); return this }
val cfg = HttpClient().applyIt {
timeout = 5 } // 内部可直接用 timeout
// 5) 可空与默认值：函数类型也能有
typealias Handler = (msg: String?, code: Int = 0) -> Unit
// val h: Handler = {
msg, code -> } // code 有默认值
// Kotlin → Java：非空参数在 Java 侧可能收到 null，需显式校验
fun fromJava(JavaImpl: (String) -> Unit) {
JavaImpl("x") }
// 6) 成员函数的 :: 要绑实例
class Repo {
fun handle(item: Item) {
}
fun wrong() {
listOf(1).forEach(::handle) } // 编译错：未绑定引用
fun right() {
listOf(1).forEach {
handle(it) } } // 正确
fun alsoRight() {
val h = ::handle; h(Repo(), 1) } // 显式带接收者
}
这段代码值得盯三处：第一处，第 1 段把"函数类型的变量调用（带括号）"与"函数引用的取法（不带括号）"并列，注释标出 f(1) 编译成 f.invoke(1)；第二处，第 3 段把"同名不同义的 typealias 不安全"与"用接口做名义隔离"对照，注释直接写出"若两者别名相同，编译不报错"；第三处，第 6 段用 wrong()/right() 两个函数名直接表达成员函数 :: 引用的坑，比抽象描述更直观。
这题在面试里怎么问、怎么答
"函数类型和单方法接口怎么选？"给判据五条：①只有一个方法 → 函数类型（更短、享受型变与空安全）；②需要多个方法 → 接口；③需要被多个实现继承/实现 → 函数类型（一个接口多个实现也可以，但函数类型更轻）；④需要名义上的类型隔离（两个语义不同但结构相同）→ 接口，因为函数类型结构相同就等于同类型；⑤需要多参数、可空、默认值 → 函数类型（接口的默认参数靠重载，麻烦）。
"typealias 能给泛型类起别名吗？"答：可以，typealias Box<T> = MyBox<T>。但不能给别名再加型变标注（typealias B<out T> 非法）；要加型变得声明 interface 或直接改原类型。同理 typealias 也不能有 companion object、不能继承。
":: 引用的类型是什么？"答：KFunction0~KFunctionN、KProperty0~KProperty2、KClass。它们都是函数式的接口，可以作为值传递。成员函数的 :: 是未绑定的（类型里含接收者），需要 obj::method 才是已绑定。
"使用中遇到过什么问题？"案例一：两个业务包各自定义了同名 typealias Callback = (Result<Any>) -> Unit，工具函数混用后行为错乱；修复为改用接口或区分参数类型。案例二：把 ::handle 直接传进 forEach，编译报错后不明所以；修复为改成 { handle(it) }。案例三：第三方 SDK 的回调在 Java 侧传了 null，Kotlin 侧直接崩；修复为把参数声明为可空。
再补一个工程上值得讲清的一点：typealias 最该用的地方是"长签名 + 高频出现"，而不是"到处都起别名"。 好的候选：typealias Json = String、typealias ViewBinding 类、typealias ApiResult<T> = Result<T>、typealias ClickListener = (View) -> Unit；不好的候选：给每个领域模型都起别名（(User) -> Boolean 已经够清楚）、给只有一两处出现的长泛型起别名（反而多一次跳转）。判断标准是"读签名时这个别名是否让人一眼看懂语义"——(Int) -> Boolean 起名叫 IntPredicate 并没有变清楚。所以团队里最好有一份"约定别名清单"，而不是各自随手起。
给正在准备面试的你
把这题画成一张"类型系统的三个层次"图：底层是 JVM 的接口（Function1<P1,R> 有 invoke），中层是 Kotlin 的函数类型语法（(P1) -> R，型变固定为 in P1, out R），上层是 typealias（编译期展开，零运行时代价）。三层之间用向上箭头标"语法糖"，旁边写清楚"哪一层有类型安全加成"。图的右侧画一个"选型决策"流程：单方法 → 函数类型；多方法或需名义隔离 → 接口；长签名且高频 → typealias。三层图 + 决策流程，就是这题的完整答案。
再补工程案例与踩坑——应用落点是给项目里高频出现的长回调签名逐个起别名，并集中到 Aliases.kt；检查是否存在"同名不同义"的别名并改为接口；跨 Java 边界的回调参数显式可空；把 :: 误用的位置改成 lambda。
复习时别孤立刷题：泛型型变 in 与 out——声明处型变的规则是out 只出现在返回位、in 只出现在参数位，函数类型(T) -> R正好一前一后踩在这两个位置上，是这条规则最直观的落点，先把位置约束理清再看回调。
划两句重点：函数类型就是 FunctionN 接口，调用带括号（f(1) = f.invoke(1)），函数引用不带括号；typealias 是纯编译期别名，零运行时代价、零类型隔离；同名不同义的回调用接口而非 typealias；跨 Java 边界的回调参数要显式可空；成员函数的 :: 是未绑定引用。
下一篇聊协程入门：suspend 到底挂起了谁——沿着今天这条主线继续往前走。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：泛型型变-in-与-out：声明处型变
下一篇预告：协程入门：suspend-到底挂起了谁
有任何问题欢迎在评论区留言交流。
