类型推断与基本类型放在一起讲，是因为它们在 Kotlin 里被重新设计过。Kotlin 取消了基本类型与包装类型在声明处的区分，Int 就是 int，Int? 才是包装的 Integer。 这一改带来的收益（无装箱陷阱、统一的 equals/toString 语义）背后有一整套机制，而 Android 上还有一层特殊考虑：Kotlin 的基本类型在字节码层面会重新装箱成 Integer。这题答好，靠的是把"语言层的简化"和"运行层的现实"分开讲清。
先把结论放在前面：Kotlin 只有一种数值类型表示，Int/Long/Double 等对应 JVM 的基本类型，Int?/Long? 等对应包装类型。可空性是唯一的分界线——不可空用基本类型，可空用包装类型。 由此推出几条实用规则：数字字面量在下划线与进制上的可读性优化（1_000_000、0xFF、0b1010）、算术运算不做隐式提升（Int + Long 编译报错，必须显式 toLong()）、以及数值转换方法名（toInt()/toLong()/toDouble()）把 Java 里混乱的 (int) longValue 换成了可读的链式。
机制拆解
装箱发生在哪里，是这题的关键。写 val a: Int = 1，Kotlin 编译器把它编译成基本类型的字段与操作，字节码里没有 Integer 对象；写 val b: Int? = 1，为了让"可能为 null"这个状态存在，必须用 Integer 引用，于是这里发生装箱。 也就是说：Kotlin 的"无装箱"是在语言抽象层面的收益，落到 JVM 上，非空基本类型仍可能被装箱——典型场景是泛型容器与接口边界。List<Int> 里放的是 Integer 对象（泛型不允许基本类型），fun <T> id(x: T): T 的 T 也是引用类型。所以 JVM 的装箱并不会因为用了 Kotlin 而消失，只是被限制在了更少的地方。
java.lang.Integer 与 int 混用的历史问题在 Kotlin 里被消掉了：Kotlin 只有 Int（引用不可空）与 Int?（可能为 null，引用可空）两个概念，没有"第三种"基本类型。 Java 里 Integer 的 == 比较引用、equals 比较值这一著名陷阱也不存在——Kotlin 的 == 就是值比较（编译为 equals），Kotlin 里根本没有原始类型包装对象的引用比较语义。
算术不隐式提升是另一个可讲的点。 Java 里 long x = 1 + 2; 通过（小整数会自动提升到 long），但 int y = intVal + longVal; 编译失败——Java 的提升规则偏向"让小类型无损变大"，Kotlin 则更明确：val l: Long = 1 + 2 编译通过（字面量常量会被推断为 Long），但 val l: Long = intA + intB 也通过（结果 Int？ ——实际 Kotlin 里 Int + Int = Int，赋给 Long 报错）。这种"严格但可预期"的风格，避免了类型被悄悄放大的隐式行为。
这些坑的正确绕法
最常见的坑是把 Int 赋给 Long 编译失败，误以为是编译器缺陷。 表现是 val l: Long = intA + intB 报类型不匹配，或者 val l = intA 之后 l + 1 报错。这类代码在 Java 里写惯了会觉得很别扭。对策是显式转换：val l = intA.toLong()，或用字面量后缀 1L。 Kotlin 提供了完整的转换方法（toByte/toShort/toInt/toLong/toFloat/toDouble/toChar），链式写法可读性也好。
其次是可空数值参与运算，需要额外的取值逻辑。 表现是 val n: Int? = ... 之后 n + 1 报错。Kotlin 不会隐式做 ?: 0 的兜底，理由是静默地把"没有值"当成 0 往往是 bug 来源（0 与"无"在业务上含义不同）。 正确做法是显式表达：给默认值 val m = n ?: 0，或者在 requireNotNull(n) { "..." } 里给出明确的失败原因。
还有一个更隐蔽的坑：在泛型与数值混用处丢掉类型信息，导致溢出或精度损失。 典型是把一个 Long 的 id 声明成 Int，超过 21 亿后溢出成负数——这类 bug 在测试数据小的时候发现不了。还有 Double 参与金额计算引入浮点误差，金融场景应该用 BigDecimal。 Kotlin 侧可以直接用 java.math.BigDecimal，但要注意除法需要指定精度与舍入模式，否则抛 ArithmeticException。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
// 1) 可读性：下划线与进制字面量
val million = 1_000_000 // 分组，不影响值
val mask = 0xFF // 十六进制
val bits = 0b1010_1010 // 二进制
val longLit = 1L // Long 字面量后缀
// 2) 严格类型：无隐式提升
val i: Int = 1
// val l1: Long = i + 1 // 编译错误：Int + Int = Int
val l2: Long = i.toLong() + 1L // 显式转换
val l3: Long = 1L + 2 // 字面量常量可直接推断为 Long
// 3) 可空数值：必须显式兜底，不做隐式 0
val n: Int? = readCount()
val m = n ?: 0 // 显式给默认值
val req = requireNotNull(n) {
"count 未初始化" } // 明确失败原因
// val bad = n + 1 // 编译错误：可空不能直接参与运算
// 4) == 做的是值比较，没有引用比较的坑
val a: Int? = 1000
val b: Int? = 1000
val same = (a == b) // true，编译为 equals
// 5) 装箱只发生在引用边界
val boxed: List<Int> = listOf(1, 2, 3) // 底层是 ArrayList<Integer>，有装箱
fun <T> identity(x: T): T = x // T 是引用类型
val b2: Integer? = i // 显式装箱类型，Java 侧友好
// 6) 金额与范围：Long + BigDecimal
val userId: Long = 5_000_000_000L // Int 会溢出
val price = java.math.BigDecimal("19.99")
val total = price.multiply(BigDecimal("3")).setScale(2, RoundingMode.HALF_UP)
val per = price.divide(BigDecimal("3"), 2, RoundingMode.HALF_UP) // 除法需指定精度
这段代码值得盯三处：第一处，million/mask 这类字面量写法不影响任何语义，纯粹是可读性，面试里用来展示"语言为可读性做的设计"；第二处，a == b 编译成 equals，没有 == 比较引用的坑，这是 Kotlin 相对 Java 的实质改进；第三处，userId: Long 与 BigDecimal 的除法精度——两个都是真实线上事故的高发点。
这题在面试里怎么问、怎么答
"Kotlin 为什么没有基本类型和包装类型的区分？"答：为了统一语义。Java 里 int/Integer 的分裂带来三堆麻烦——装箱开销、== 与 equals 的语义分裂、以及泛型与原始类型的不一致。Kotlin 用"可空性"作为唯一分界线：不可空 → 基本类型，可空 → 包装类型，声明处不需要区分。 代价是泛型边界仍会装箱（List<Int> 底层是 Integer），所以这个收益有边界。
"类型推断是怎么工作的？会不会有坑？"答：Kotlin 从声明的期望类型向下约束字面量类型（val l: Long = 1 里 1 被推断为 Long），从显式类型的变量向上约束调用参数。 坑主要在三处：①公共 API 里不要依赖推断，显式写类型，否则调用方看到的签名变化会造成二进制不兼容；②数值字面量的推断方向容易让人误解（val d = 1 是 Int 不是 Double）；③Lambda 参数类型要靠期望类型推断，混用时容易拿到 Any。
"Long 和 Int 混用要注意什么？"给三条：①id、时间戳、计数一律用 Long，Int 上限 21 亿并不遥远；②转换要显式，别指望自动提升；③序列化时注意 JS 与 JSON 里数字精度问题，超过 2^53 的 Long 在 JavaScript 里会丢精度。
"使用中遇到过什么问题？"案例一：用户 id 字段声明为 Int，某天数据量超过 21 亿后出现负数 id；定位到溢出；修复为改 Long 并检查所有落库与传输字段的类型宽度。案例二：金额用 Double 累加出现 0.1 + 0.2 != 0.3 类偏差；定位到浮点误差；修复为改 BigDecimal 并统一舍入模式。
再补一个工程上值得讲清的点：Kotlin 侧基本类型与 Java 侧 API 交互时的两处细节。 一是 Long 在 Java 方法上对应 long 还是 Long 取决于可空性，调用 TextUtils/Bundle 这些 API 时如果参数是可空类型，可能遇到类型不匹配，需要 ?: 或 !! 之外的处理；二是 Java 的原始类型在 Kotlin 里表现为平台类型（String!），可以当可空也可当非空用，调用 String.length 不会报错但可能运行期 NPE——这就是"平台类型"在数值与字符串场景的体现。 混编项目里给 Java API 的返回值统一加 ?. 或显式判空，比依赖平台类型的宽松更安全。
给正在准备面试的你
把这题画成一张"两条轴"的对角图：横轴是可空性（不可空 / 可空），纵轴是运行层表示（基本类型 / 包装类型）。四个格子里写：Int（基本）、Int?（Integer）、List<Int> 的元素（Integer，泛型强制引用）、以及 fun <T> id(x: T) 的 T（引用）。 在图外标注两条结论：语言层统一了声明，JVM 层装箱仍发生在泛型与接口边界。再在图下方写一条"不需要记的坑"：== 无引用比较语义。最后把 1_000_000、toLong()、?: 0 三个示例贴在旁边作为落地锚点。面试中类型相关的问题都能从这张图推出来。
再补工程案例与踩坑——应用落点是全项目搜一遍 Int 类型的 id/时间戳/计数字段，逐一确认是否需要改成 Long；把金额相关的 Double 运算收敛到统一工具类改用 BigDecimal；给公共 API 显式声明参数与返回类型而不是依赖推断。
复习时别孤立刷题：val 与 var——val + 不可变对象是 Kotlin 的默认方向，数值类型同理，优先选语义更明确的那个。
划两句重点：Kotlin 用可空性替代基本/包装之分，但装箱仍发生在泛型与接口边界；== 做的是值比较；算术不隐式提升，需 toLong()；可空数值必须显式 ?: 兜底；id 与时间戳用 Long，金额用 BigDecimal。
下一篇聊空安全入门：?、!! 与 ?. 的三分天下——沿着今天这条主线继续往前走。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：val-与-var：不可变优先的工程哲学
下一篇预告：空安全入门：?、!! 与 ?. 的三分天下
有任何问题欢迎在评论区留言交流。
