扩展函数必须定义在顶层文件中，如fun context.toast(text: charsequence) { toast.maketext(this, text, toast.length_short).show() }，不可在类、companion object或函数内声明。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 免费无限量使用 DeepSeek R1 模型☜☜☜
扩展函数怎么写才不报错：fun Context.toast() 这种写法为什么编译不过
Kotlin 扩展函数必须定义在顶层（即类外部），不能写在另一个函数内部，也不能写在 companion object 里——否则会提示 Extension function must be declared at top level。
常见错误是把扩展函数当成普通工具函数塞进某个 Activity 或 ViewModel 里，结果死活编译不通过。
- 必须放在
.kt文件的最外层，和普通函数平级 - 接收者类型（如
Context）不能是空类型或泛型未绑定类型，比如fun <t> T.foo()</t>要确保调用时能推导出具体类型 - Android 中常用
Context、View、Fragment做接收者，但注意Context扩展不能直接访问this.resources等成员——它只是语法糖，不是继承，所有访问仍走原对象的公开 API
正确示例：
fun Context.toast(text: CharSequence) {
Toast.makeText(this, text, Toast.LENGTH_SHORT).show()
}
扩展属性为什么不能存值：var View.isSafeLayout: Boolean 报 Backing field is not allowed
扩展属性不能有 backing field（即不能自动带 private set 或默认存储），因为 Kotlin 扩展不修改原有类结构，只是“假装”它多了个属性。
你写的 get() 和 set() 必须完全自包含，不能依赖隐藏字段。
- 只读扩展属性用
val+get()即可，比如val View.isVisible: Boolean get() = this.visibility == View.VISIBLE - 可写扩展属性必须自己找地方存值，常见做法是用
WeakHashMap<view boolean></view>缓存，或借助View.setTag()（注意 key 要唯一，推荐用R.id.xxx） - 别试图在扩展属性里用
this.myPrivateField = ...—— 原类没这字段，运行时就NoSuchFieldException
Java 调用 Kotlin 扩展函数：为什么 MyUtilsKt.showToast(context, "hi") 这么丑还必须加 Kt 后缀
Kotlin 编译器会把顶层函数（包括扩展函数）打包进一个静态工具类，默认名是「文件名 + Kt」，所以 ToastExt.kt → ToastExtKt.class。
Java 没有扩展语法，只能当普通静态方法调用，接收者变成第一个参数。
- 想改类名？在文件顶部加
@file:JvmName("ToastUtils")，之后 Java 就能用ToastUtils.showToast(...) - 想让扩展函数对 Java 更友好，避免接收者参数暴露，可以封装一层普通函数：
fun showToast(context: Context, text: String) { context.toast(text) } - 注意：
@file:JvmMultifileClass不适用于扩展函数，它只合并普通声明，扩展函数始终独立生成
性能和生命周期风险：fun Fragment.requireActivity(): Activity 这种扩展真安全吗
官方 requireActivity() 是安全的，因为它内部检查了 isAdded 和 activity != null；但你自己写的类似扩展，很容易漏掉这些判断。
尤其在异步回调里调用扩展函数，比如 Retrofit 回调中执行 context.toast()，此时 Context 可能已销毁，直接 crash。
- 扩展函数本身不感知生命周期，所有安全逻辑得自己写：先判
this is Context && this is Activity && this.isFinishing.not() && this.isDestroyed.not() - 更稳妥的做法是用
lifecycleScope或viewLifecycleOwner.lifecycleScope做协程作用域约束，而不是靠扩展函数“假装安全” - AndroidX 的
core-ktx里很多扩展（如View.doOnNextLayout）都内置了生命周期防护，抄它的思路比自己裸写强
扩展不是银弹，它省的是调用时的语法，不是设计时的责任。写得越顺手，越容易忽略上下文是否还活着。
