希望帮你在Kotlin进阶路上少走弯路，在技术上稳步提升。当然，由于个人知识储备有限，笔记中难免存在疏漏或表述不当的地方，也非常欢迎大家提出宝贵意见，一起交流进步。 ------ Android_小雨
整体目录：Kotlin 进阶不迷路：41 个核心知识点，构建完整知识体系
一、前言
1.1 继承控制的核心意义
在面向对象编程中，继承是实现代码复用和扩展的核心机制，但不受控制的继承往往会带来诸多问题：例如子类随意重写父类核心方法导致业务逻辑紊乱，或是对设计为"不可扩展"的类进行继承引发兼容性风险。继承控制的核心价值就在于"规范类的扩展性边界"------明确哪些类允许被继承、哪些成员允许被重写，既为合理扩展提供支持，又通过限制不必要的继承和重写来保障代码的稳定性与可维护性。
想象一个场景：开发团队封装了一个支付核心类 PaymentProcessor，其中 calculateFee() 方法实现了严格的手续费计算规则。若允许子类随意重写该方法，可能导致手续费计算错误，引发财务风险。此时就需要通过继承控制，禁止该方法被重写，同时为需要扩展的非核心方法开放权限。
1.2 Kotlin 继承的默认规则（与 Java 不同，默认不可继承）
Java 中类和成员的默认访问规则是"默认可继承/重写"（除 private 修饰的成员外），若要禁止继承需显式添加 final 修饰符。而 Kotlin 采用了截然相反的设计哲学------类和成员默认是 final 的，即默认不可继承、不可重写。这种设计的初衷是"优先保障代码稳定性"，避免开发者在不知情的情况下继承了本不应扩展的类，或是重写了核心逻辑方法。
这种默认规则的差异是 Kotlin 与 Java 继承机制的核心区别之一，也是很多从 Java 转 Kotlin 开发者容易踩坑的点。例如在 Java 中可直接继承的普通类，在 Kotlin 中若未显式配置，直接继承会编译报错。
1.3 本文核心内容预告
本文将从 Kotlin 继承的默认行为入手，系统解析 final 与 open 修饰符的核心作用：首先讲解类和成员的默认 final 特性及示例；接着详细说明 open 修饰符如何开启继承与重写权限，包括类和成员层面的用法；然后阐述 final 修饰符的显式使用场景，以及如何用其覆盖 open 效果；再结合实际开发场景给出两种修饰符的选型建议；最后对比与 Java 的差异并总结最佳实践，帮助开发者精准掌握继承控制的核心技巧。
二、默认行为：Kotlin 类与成员的 "不可继承" 特性
Kotlin 为了避免不受控制的继承，将"不可继承/不可重写"设为默认行为，这种默认性体现在类和成员两个层面，下面分别解析并结合示例说明。
2.1 类的默认状态（隐式 final，无法被继承）
在 Kotlin 中，若定义类时未添加任何继承相关的修饰符，该类会被隐式标记为 final，意味着其他类无法继承它。编译器会直接拦截继承操作并报错，明确提示"该类是 final 的，无法被继承"。
这种设计强制开发者在允许继承前深思熟虑：该类是否真的需要被扩展？是否设计了足够稳定的扩展接口？避免了 Java 中"随意继承"带来的后续维护难题。
2.2 成员的默认状态（属性 / 方法隐式 final，无法被重写）
除了类本身默认 final 外，类中的所有成员（包括属性和方法）也默认是 final 的------即使父类被显式设为可继承（open 修饰），其未加修饰的成员依然不允许子类重写。这种"成员默认不可重写"的规则，进一步强化了核心逻辑的安全性，防止子类误改父类关键实现。
需要注意的是，这里的"成员"涵盖了普通方法、属性（包括自定义访问器的属性），但不包括抽象成员（抽象成员本身就是为了被重写而设计，默认隐含 open 特性）。
2.3 简单示例（默认类无法被继承、默认方法无法重写）
示例 1：默认类无法被继承
定义一个未加任何修饰的普通类 User，尝试继承该类时会编译报错，明确提示类是 final 的。
kotlin
// 未加修饰符的类，隐式为 final
class User(val id: String, val name: String) {
fun getUserName(): String {
return "用户：$name"
}
}
// 尝试继承 User 类，编译报错：Cannot inherit from final class 'User'
// class Student(id: String, name: String, val studentNo: String) : User(id, name) {
// // 子类逻辑
// }
fun main() {
val user = User("1", "张三")
println(user.getUserName()) // 输出：用户：张三
}示例 2：父类开放继承后，默认成员仍无法重写
若显式用 open 修饰父类使其可继承，但未修饰成员，子类尝试重写成员时依然会报错，体现"成员默认 final"的特性。
kotlin
// 用 open 修饰，允许该类被继承
open class User(val id: String, val name: String) {
// 未加修饰符的方法，隐式为 final
fun getUserName(): String {
return "用户：$name"
}
// 未加修饰符的属性，隐式为 final
val userId: String
get() = "ID:$id"
}
// 子类继承 User 类（合法，因父类是 open 的）
class Student(id: String, name: String, val studentNo: String) : User(id, name) {
// 尝试重写父类的 getUserName 方法，编译报错：'getUserName' in 'User' is final and cannot be overridden
// override fun getUserName(): String {
// return "学生：$name（学号：$studentNo）"
// }
// 尝试重写父类的 userId 属性，编译报错：'userId' in 'User' is final and cannot be overridden
// override val userId: String
// get() = "学生ID:$id"
}
fun main() {
val student = Student("2", "李四", "2024001")
println(student.getUserName()) // 输出：用户：李四（调用父类方法）
println(student.userId) // 输出：ID:2（调用父类属性）
}三、open 修饰符：开启继承与重写权限
若需要类支持继承、成员支持重写，Kotlin 提供了 open 修饰符------这是"打破默认 final 限制"的唯一方式。open 修饰符可分别作用于类和成员，二者需配合使用：只有父类是 open 的，子类才能继承；只有父类成员是 open 的，子类才能重写该成员。
3.1 open 修饰类（允许该类被其他类继承）
3.1.1 语法格式（open 关键字修饰类名）
open 修饰类的语法非常简洁，只需在 class 关键字前添加 open 关键字即可。语法格式如下：
arduino
// open 修饰类，允许被继承
open class 类名(构造函数参数) {
// 类成员
}需要注意的是，open 仅能修饰普通类，不能修饰密封类（sealed class）、枚举类（enum class）等特殊类------这些类本身就有明确的设计约束，不支持继承。
3.1.2 示例（定义可继承的父类）
定义一个 open 修饰的基础类 Animal，然后创建 Dog 和 Cat 两个子类继承它，实现类的扩展。
kotlin
// open 修饰，允许被继承的基础类
open class Animal(val name: String) {
// 暂时不开放重写的方法
fun getAnimalName(): String {
return "动物名称：$name"
}
}
// 子类 Dog 继承 Animal（合法，父类是 open 的）
class Dog(name: String, val breed: String) : Animal(name) {
// 子类特有方法
fun bark() {
println("$name 汪汪叫")
}
}
// 子类 Cat 继承 Animal（合法）
class Cat(name: String, val color: String) : Animal(name) {
// 子类特有方法
fun meow() {
println("$name 喵喵叫")
}
}
fun main() {
val dog = Dog("旺财", "中华田园犬")
println(dog.getAnimalName()) // 输出：动物名称：旺财
dog.bark() // 输出：旺财 汪汪叫
val cat = Cat("咪宝", "橘色")
println(cat.getAnimalName()) // 输出：动物名称：咪宝
cat.meow() // 输出：咪宝 喵喵叫
}从示例可见，open 修饰的父类允许子类继承并扩展特有功能，同时父类未开放的成员（如 getAnimalName）子类可正常调用但不能修改，保证了父类核心逻辑的稳定。
3.2 open 修饰成员（允许子类重写该属性 / 方法）
仅开放类的继承权限还不够，若需要子类定制父类的某些逻辑，需在父类对应的成员（属性或方法）前添加 open 修饰符，明确允许该成员被重写。子类重写时需添加 override 关键字，形成"父类开放-子类显式重写"的清晰链路。
3.2.1 语法格式（open 关键字修饰属性 / 方法）
open 修饰成员的语法是在属性或方法的定义前添加 open 关键字，子类重写时需添加 override 关键字。语法格式如下：
kotlin
// open 修饰父类
open class 父类名 {
// open 修饰方法，允许重写
open fun 方法名(参数): 返回值类型 {
// 父类实现
}
// open 修饰属性，允许重写
open val 属性名: 属性类型 = 初始值
}
// 子类继承并重写成员
class 子类名 : 父类名() {
// override 关键字重写方法
override fun 方法名(参数): 返回值类型 {
// 子类实现
}
// override 关键字重写属性
override val 属性名: 属性类型 = 新值
}需要注意的是，override 关键字是强制要求的，即使子类方法签名与父类完全一致，未加 override 也会编译报错------这种显式约束避免了"无意识重写"的问题。
3.2.2 示例（父类开放可重写的方法）
定义 open 修饰的父类 Shape，开放 calculateArea() 方法和 shapeName 属性允许重写，然后子类 Circle 和 Rectangle 重写这些成员实现各自的逻辑。
kotlin
// open 修饰父类，允许继承
open class Shape {
// open 修饰属性，允许重写
open val shapeName: String = "形状"
// open 修饰方法，允许重写
open fun calculateArea(): Double {
// 父类默认实现（可返回 0.0 或抛出异常，视场景而定）
println("未指定具体形状，无法计算面积")
return 0.0
}
}
// 子类 Circle 继承 Shape 并重写成员
class Circle(val radius: Double) : Shape() {
// override 重写属性
override val shapeName: String = "圆形"
// override 重写方法，实现圆形面积计算
override fun calculateArea(): Double {
val area = Math.PI * radius * radius
println("$shapeName 面积：${String.format("%.2f", area)}")
return area
}
}
// 子类 Rectangle 继承 Shape 并重写成员
class Rectangle(val width: Double, val height: Double) : Shape() {
// override 重写属性
override val shapeName: String = "矩形"
// override 重写方法，实现矩形面积计算
override fun calculateArea(): Double {
val area = width * height
println("$shapeName 面积：${String.format("%.2f", area)}")
return area
}
}
fun main() {
val shape: Shape // 父类引用
shape = Circle(5.0) // 子类对象
shape.calculateArea() // 输出：圆形 面积：78.54
println("形状名称：${shape.shapeName}") // 输出：形状名称：圆形
shape = Rectangle(4.0, 6.0) // 子类对象
shape.calculateArea() // 输出：矩形 面积：24.00
println("形状名称：${shape.shapeName}") // 输出：形状名称：矩形
}示例中，父类通过 open 明确开放了可扩展的接口，子类通过 override 显式重写，既实现了代码复用（继承父类结构），又完成了逻辑定制（重写计算方法），同时避免了无意识的重写风险。
四、final 修饰符：强制关闭继承与重写
final 修饰符的作用与 open 相反，用于"强制关闭继承或重写权限"。由于 Kotlin 类和成员默认就是 final 的，所以 final 更多用于"覆盖 open 效果"------例如父类是 open 的，但某个子类需要禁止被进一步继承；或是父类成员是 open 的，但某个子类重写后希望禁止后续子类再重写。
4.1 final 修饰类（明确禁止类被继承，与默认行为一致）
4.1.1 语法格式（final 关键字修饰类名）
final 修饰类的语法是在 class 关键字前添加 final 关键字，格式如下：
arduino
// final 修饰类，禁止被继承
final class 类名(构造函数参数) {
// 类成员
}需要强调的是，由于类默认就是 final 的，直接定义未加修饰的类与显式加 final 修饰的类在功能上完全一致。final 修饰类的核心使用场景是"在继承链路中中途关闭继承"------例如父类是 open 的，子类继承后用 final 修饰，确保该子类不能被进一步继承。
4.1.2 示例（定义不可继承的工具类）
工具类通常包含固定的通用逻辑，不需要也不应该被继承（避免子类修改通用逻辑导致功能异常），此时可显式用 final 修饰类，明确其"不可继承"的定位------即使后续开发者误尝试继承，编译器也会及时提醒。
kotlin
// final 修饰工具类，明确禁止被继承
final class MathUtil {
// 工具方法（静态方法，通过 companion object 实现）
companion object {
// 计算两个数的最大值
fun max(a: Int, b: Int): Int {
return if (a > b) a else b
}
// 计算两个数的最小值
fun min(a: Int, b: Int): Int {
return if (a < b) a else b
}
}
}
// 尝试继承 MathUtil 类，编译报错：Cannot inherit from final class 'MathUtil'
// class AdvancedMathUtil : MathUtil() {
// // 试图扩展工具类，被禁止
// }
fun main() {
println(MathUtil.max(10, 20)) // 输出：20
println(MathUtil.min(10, 20)) // 输出：10
}显式添加 final 修饰工具类，不仅能阻止继承，还能向其他开发者传递"该类逻辑固定，禁止扩展"的设计意图，提升代码可读性。
4.2 final 修饰成员（禁止子类重写，覆盖 open 效果）
final 修饰成员的核心作用是"覆盖父类成员的 open 特性"------若父类成员是 open 的，子类重写该成员后可通过 final 修饰，禁止后续子类再重写该成员。这种"逐层控制重写权限"的机制，让继承链路的扩展性控制更加精细。
4.2.1 语法格式（final 关键字修饰属性 / 方法）
final 修饰成员的语法是在属性或方法定义前添加 final 关键字，通常与 override 配合使用（重写父类 open 成员后关闭重写）。格式如下：
kotlin
// open 父类
open class 父类名 {
open fun 方法名() { /* 父类实现 */ }
}
// 子类继承并重写成员，同时用 final 关闭重写
class 子类名 : 父类名() {
// override 重写 + final 禁止后续重写
final override fun 方法名() {
/* 子类实现，后续子类不可再重写 */
}
}4.2.2 示例（父类开放继承，但部分方法禁止重写）
定义 open 修饰的父类 Payment，开放 pay() 方法允许重写，但核心的 validateAmount() 方法用 final 修饰禁止重写；子类 AlipayPayment 重写 pay() 方法时，可进一步用 final 修饰禁止后续子类重写。
kotlin
// open 修饰父类，允许继承
open class Payment(val amount: Double) {
// final 修饰核心方法，禁止任何子类重写
final fun validateAmount(): Boolean {
if (amount <= 0) {
println("支付金额无效：$amount（必须大于 0）")
return false
}
println("支付金额验证通过：$amount 元")
return true
}
// open 修饰支付方法，允许子类重写（定制支付方式）
open fun pay(): Boolean {
if (!validateAmount()) {
return false
}
println("执行默认支付逻辑（未指定支付方式）")
return true
}
}
// 子类 AlipayPayment 继承 Payment，重写 pay 方法
class AlipayPayment(amount: Double, val userId: String) : Payment(amount) {
// override 重写 pay 方法，同时用 final 禁止后续子类重写
final override fun pay(): Boolean {
if (!validateAmount()) {
return false
}
println("支付宝支付：用户 $userId 支付 $amount 元成功")
return true
}
}
// 尝试继承 AlipayPayment 并重写 pay 方法，编译报错：'pay' in 'AlipayPayment' is final and cannot be overridden
// class DiscountAlipayPayment(amount: Double, userId: String, val discount: Double) : AlipayPayment(amount, userId) {
// override fun pay(): Boolean {
// // 试图重写支付宝支付逻辑，被禁止
// return super.pay()
// }
// }
fun main() {
val payment1 = Payment(100.0)
payment1.pay() // 输出：支付金额验证通过：100.0 元；执行默认支付逻辑（未指定支付方式）
val payment2 = AlipayPayment(200.0, "zhangsan123")
payment2.pay() // 输出：支付金额验证通过：200.0 元；支付宝支付：用户 zhangsan123 支付 200.0 元成功
val payment3 = AlipayPayment(-50.0, "lisi456")
payment3.pay() // 输出：支付金额无效：-50.0（必须大于 0）
}示例中，父类通过 final 保护了核心的金额验证逻辑（validateAmount），确保所有子类都必须使用统一的验证规则；同时开放支付逻辑（pay）允许子类定制，而子类 AlipayPayment 重写后用 final 关闭，确保支付宝支付逻辑不被后续子类修改，实现了"核心逻辑固定，扩展逻辑可控"的设计目标。
五、继承控制实战场景
final 与 open 修饰符的使用并非单纯的语法问题，而是与业务场景、设计意图紧密相关。下面结合实际开发中最常见的场景，解析两种修饰符的合理选型。
5.1 用 open 场景（基础类、可扩展组件，如 BaseActivity）
open 修饰符的核心使用场景是"需要被继承扩展"的类和成员，典型场景包括基础组件类、框架扩展类、抽象逻辑父类等，其中最具代表性的是 Android 开发中的 BaseActivity。
场景解析：Android 中的 BaseActivity
在 Android 开发中，所有 Activity 都有共同的逻辑（如初始化控件、设置布局、权限申请、沉浸式状态栏配置等）。此时会定义一个 open 修饰的 BaseActivity 作为父类，封装这些通用逻辑，然后具体页面的 Activity 继承 BaseActivity 并重写个性化逻辑（如布局 ID、业务数据加载）。
kotlin
import android.os.Bundle
import androidx.appcompat.app.AppCompatActivity
// open 修饰基础类，允许子类继承
open class BaseActivity : AppCompatActivity() {
// 开放布局 ID 供子类重写（抽象化布局设置）
protected open val layoutResId: Int = 0
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// 通用逻辑：设置布局
if (layoutResId != 0) {
setContentView(layoutResId)
}
// 通用逻辑：初始化沉浸式状态栏
initStatusBar()
// 通用逻辑：初始化控件
initViews()
// 通用逻辑：加载数据
loadData()
}
// 通用逻辑：沉浸式状态栏配置（固定逻辑，禁止重写）
private fun initStatusBar() {
println("执行沉浸式状态栏配置")
// 具体实现代码...
}
// 开放方法供子类重写：初始化控件
protected open fun initViews() {}
// 开放方法供子类重写：加载数据
protected open fun loadData() {}
}
// 具体页面的 Activity 继承 BaseActivity
class HomeActivity : BaseActivity() {
// 重写布局 ID，指定当前页面布局
override val layoutResId: Int = R.layout.activity_home
// 重写初始化控件方法，实现个性化控件初始化
override fun initViews() {
super.initViews()
println("HomeActivity 初始化控件")
// 具体控件初始化代码...
}
// 重写加载数据方法，实现个性化数据加载
override fun loadData() {
super.loadData()
println("HomeActivity 加载首页数据")
// 具体数据加载代码...
}
}该场景中，BaseActivity 用 open 修饰允许继承，同时通过 open 开放了布局 ID 和核心方法供子类定制，而固定的通用逻辑（如 initStatusBar）用 private 修饰（隐含 final 特性）禁止修改，既实现了代码复用，又保证了基础逻辑的稳定性。
5.2 用 final 场景（工具类、固定逻辑类，如 MathUtil）
final 修饰符的核心使用场景是"逻辑固定、不允许扩展"的类和成员，典型场景包括工具类、常量类、第三方 SDK 封装类等，这些类的核心诉求是"提供稳定的功能，避免被修改"。
场景解析：通用工具类 MathUtil
数学工具类、字符串工具类等通用工具类，其方法实现通常是标准化的（如求最大值、字符串脱敏），一旦被子类重写可能导致功能异常（例如子类修改 max 方法逻辑导致计算错误）。此时用 final 修饰类，明确禁止继承，同时方法用 private 或 final 修饰禁止重写，确保功能稳定性。
kotlin
// final 修饰工具类，禁止继承
final class StringUtil {
companion object {
// 字符串脱敏方法（固定逻辑，禁止重写）
fun desensitizePhone(phone: String): String {
if (phone.length != 11) {
return "无效手机号"
}
// 保留前 3 位和后 4 位，中间用 * 代替
return phone.substring(0, 3) + "****" + phone.substring(7)
}
// 字符串空判断方法（固定逻辑，禁止重写）
fun isEmpty(str: String?): Boolean {
return str == null || str.trim().isEmpty()
}
}
}
fun main() {
println(StringUtil.desensitizePhone("13800138000")) // 输出：138****8000
println(StringUtil.isEmpty(" ")) // 输出：true
println(StringUtil.isEmpty("hello")) // 输出：false
}该场景中，StringUtil 用 final 修饰确保无法被继承，方法通过 companion object 实现静态调用且逻辑固定，任何试图修改的行为都会被编译器拦截，有效保障了工具类的可靠性。
5.3 混合使用场景（父类开放继承，核心方法禁止重写）
实际开发中更多的是混合场景：父类需要被继承以实现扩展，但部分核心逻辑必须固定，不允许子类修改。此时需结合 open 和 final 实现"选择性开放"------类用 open 修饰允许继承，核心成员用 final 修饰禁止重写，非核心成员用 open 修饰允许定制。
场景解析：支付服务父类 PaymentService
支付服务包含统一的流程（如日志记录、异常处理、金额验证）和差异化的流程（如具体支付接口调用）。定义 open 修饰的 PaymentService 作为父类，将统一流程用 final 修饰固定，差异化流程用 open 修饰开放，子类只需实现差异化部分即可。
kotlin
// open 修饰父类，允许子类继承扩展
open class PaymentService(val orderId: String, val amount: Double) {
// 核心流程：支付前验证（固定逻辑，禁止重写）
final fun prePay(): Boolean {
println("【支付前置】订单 $orderId 开始验证")
// 1. 金额验证
if (amount <= 0) {
println("【支付前置】订单 $orderId 金额无效：$amount")
return false
}
// 2. 订单状态验证
if (!checkOrderStatus()) {
println("【支付前置】订单 $orderId 状态无效")
return false
}
println("【支付前置】订单 $orderId 验证通过")
return true
}
// 核心流程：支付后处理（固定逻辑，禁止重写）
final fun postPay(success: Boolean) {
if (success) {
println("【支付后置】订单 $orderId 支付成功，记录日志")
// 记录支付成功日志、更新订单状态等固定逻辑...
} else {
println("【支付后置】订单 $orderId 支付失败，触发重试")
// 记录失败日志、触发重试机制等固定逻辑...
}
}
// 开放方法：订单状态验证（允许子类定制，如不同平台订单状态校验）
open fun checkOrderStatus(): Boolean {
println("【默认订单校验】订单 $orderId 状态正常")
return true
}
// 开放抽象方法：具体支付逻辑（必须由子类实现）
open fun doPay(): Boolean {
throw UnsupportedOperationException("子类必须实现具体支付逻辑")
}
// 统一支付入口（固定流程，禁止重写）
final fun pay(): Boolean {
// 1. 支付前置验证
if (!prePay()) {
return false
}
// 2. 具体支付逻辑（子类实现）
val paySuccess = doPay()
// 3. 支付后置处理
postPay(paySuccess)
return paySuccess
}
}
// 微信支付子类，继承并实现差异化逻辑
class WechatPaymentService(orderId: String, amount: Double, val openId: String) : PaymentService(orderId, amount) {
// 重写订单状态校验（微信平台定制校验）
override fun checkOrderStatus(): Boolean {
println("【微信订单校验】校验 openId $openId 关联的订单 $orderId 状态")
// 微信平台特有的订单状态校验逻辑...
return true
}
// 重写具体支付逻辑（微信支付接口调用）
override fun doPay(): Boolean {
println("【微信支付】调用微信支付接口：openId=$openId，金额=$amount")
// 调用微信支付 SDK 等具体逻辑...
return true // 模拟支付成功
}
}
// 支付宝支付子类，继承并实现差异化逻辑
class AlipayPaymentService(orderId: String, amount: Double, val alipayAccount: String) : PaymentService(orderId, amount) {
// 重写具体支付逻辑（支付宝支付接口调用）
override fun doPay(): Boolean {
println("【支付宝支付】调用支付宝支付接口：账号=$alipayAccount，金额=$amount")
// 调用支付宝支付 SDK 等具体逻辑...
return true // 模拟支付成功
}
}
fun main() {
println("=== 微信支付流程 ===")
val wechatPay = WechatPaymentService("ORDER001", 199.0, "o6_bmjrPTlm6_2sgVt7hMZOPfL2M")
wechatPay.pay()
println("\n=== 支付宝支付流程 ===")
val alipay = AlipayPaymentService("ORDER002", 299.0, "zhangsan@alipay.com")
alipay.pay()
}该场景中，父类通过 final 固定了支付的核心流程（前置验证、后置处理、统一入口），确保所有支付方式都遵循相同的规范；同时通过 open 开放了差异化接口（订单校验、具体支付），子类只需聚焦自身的业务逻辑，既保证了一致性，又兼顾了扩展性。
六、总结与使用建议
6.1 核心知识点回顾
本文围绕 final 与 open 修饰符展开，核心知识点可归纳为"一个默认规则、两个修饰符作用、三层控制粒度"：
- 一个默认规则：Kotlin 类和成员默认是 final 的，即默认不可继承、不可重写，优先保障代码稳定性。
- 两个修饰符作用：open 用于开启权限（类允许继承、成员允许重写）；final 用于关闭权限（类禁止继承、成员禁止重写），可覆盖 open 效果。
- 三层控制粒度：类级别（控制是否可继承）、成员级别（控制是否可重写）、继承链路级别（子类可通过 final 中途关闭继承或重写）。
6.2 与 Java 的区别
Kotlin 与 Java 在继承控制上的设计理念截然不同，核心区别体现在默认规则和修饰符使用上，具体对比如下：
| 对比维度 | Kotlin | Java |
|---|---|---|
| 类的默认状态 | final（不可继承） | 非 final（默认可继承） |
| 成员的默认状态 | final（不可重写，除非类和成员都 open） | 非 final（默认可重写，除非显式 final） |
| 重写关键字要求 | 必须显式添加 override 关键字 | 无需显式关键字，方法签名一致即可重写 |
| 设计理念 | 优先稳定，按需开放扩展 | 优先灵活，按需关闭扩展 |
从 Java 转 Kotlin 开发时，需重点关注这种默认规则的差异，避免因"习惯性继承"导致编译报错，或因"忘记加 open"导致无法扩展。
6.3 最佳实践（按需开放继承，核心逻辑用 final 保护）
结合 Kotlin 的设计理念和实战场景，总结以下 final 与 open 的最佳使用原则，帮助开发者在实际开发中精准应用：
- 遵循"最小权限原则"，按需开放扩展：除非明确需要被继承，否则类和成员都保持默认的 final 状态。开放扩展时，优先开放具体的成员而非整个类------例如仅开放需要重写的方法，而非将整个类设为 open 后让所有成员都可重写。
- 核心逻辑必须用 final 保护：涉及业务规范、数据安全、流程一致性的核心逻辑（如支付验证、权限校验、工具类方法），必须用 final 修饰禁止重写，确保所有子类都遵循统一规则，避免因子类修改导致的隐患。
- 显式添加修饰符传递设计意图：对于工具类、常量类等明确不可继承的类，显式添加 final 修饰符，向其他开发者传递"禁止扩展"的设计意图；对于基础类、扩展类等明确可继承的类，显式添加 open 修饰符，避免后续开发者误删关键修饰符。
- 重写时显式调用父类方法（super） ：子类重写 open 成员时，若父类实现包含必要的逻辑（如初始化、资源释放），需显式调用 super.方法名() 确保父类逻辑执行，避免因重写导致父类逻辑丢失。
- 避免多层继承，减少 final/open 管理复杂度：多层继承会导致继承链路复杂，final 和 open 的作用范围难以追踪。建议采用"单继承 + 多实现"的方式（继承基础类，实现接口），简化继承结构，降低扩展控制的复杂度。
最后用一句口诀总结核心原则："默认 final 保稳定，按需 open 做扩展；核心逻辑加 final，显式修饰传意图"。遵循这一原则，既能充分利用 Kotlin 继承控制的优势保障代码稳定，又能为合理扩展提供灵活支持，实现"稳定与灵活的平衡"。