去年某大厂Spark岗位面了127人，通过率11%。HR后来复盘发现，挂掉的候选人里八成不是不懂分布式计算，而是被Scala语言细节绊倒——比如有人把val和var的区别说成"就是个命名习惯"，直接出局。
这篇整理自50道高频面试题，覆盖从语法基础到生产踩坑的全链条。不管你是准备跳槽的工程师，还是筛人筛到头疼的面试官，都能用得上。
第一关：语法基础——面试官最爱挖坑的5个地方
这5道题看似简单，但"坏答案"和"好答案"的差距，直接暴露候选人有没有在生产环境写过代码。
第一题：val和var的区别。坏答案说是"两种创建变量的方式，没实质区别"；好答案必须点出val的不可变特性在分布式场景的价值——跨执行器共享可变状态是Spark作业里最隐蔽的bug来源之一。
第二题：模式匹配。很多人答成"加强版switch-case"，但面试官想听的是解构能力——类型匹配、case class字段提取、嵌套结构处理，以及和密封特质（sealed trait）配合做穷尽检查。DataFrame转换里这玩意儿用得极多。
第三题：case class。坏答案说"编译器让它变特殊"；好答案要列出生成的5样东西：equals、hashCode、toString、copy、伴生对象的apply和unapply。再加上不可变默认、易序列化、和Encoder配合做Dataset schema——这才是Spark开发者该有的视角。
第四题：trait vs 抽象类。核心区别在多重继承和构造参数。Scala 3之前trait不能带构造参数，抽象类可以。管道代码里堆叠行为时trait更灵活。
第五题：Option。有人抱怨"让代码变长"，但好答案要解释它如何强制处理空值——在分布式数据流里，null的传播成本远高于提前用None显式标记。
第二关：隐式转换——从"魔法"到可控的边界
隐式（implicits）是Scala面试的分水岭。懂的人觉得顺手，不懂的人觉得"这语言怎么到处偷偷改我代码"。
题目6-10聚焦这块。典型问法：隐式参数和隐式转换的区别？隐式解析的优先级规则？为什么Spark SQL的Dataset能自动推断编码器？
一个高频踩坑点：候选人能背出"隐式参数在编译时注入"，但说不清楚隐式作用域的查找顺序——当前作用域、导入的隐式、伴生对象。生产环境里找不到隐式实现的报错，八成是作用域问题。
另一个考点：隐式转换的滥用边界。Spark早期版本大量用隐式增强RDD，但Scala 3开始推given和using显式化。面试时提到这个演进，能加分。
题目还涉及类型类（type class）模式。这是函数式编程里用隐式实现多态的核心技巧，Spark的Encoder、Ordering都是典型实现。能手绘一个简化版类型类定义，说明白和Java接口的区别，基本稳过这轮。
第三关：集合与函数式——分布式场景的语法映射
Spark的map、filter、reduce和Scala集合的同名操作，执行模型完全不同，但语法高度相似。面试常考这种"看起来一样，底层两回事"的陷阱。
题目11-20覆盖不可变集合的持久化数据结构、懒加载流（LazyList/Stream）、尾递归优化、偏函数、柯里化等。一个经典陷阱：问List和Vector的随机访问复杂度，候选人背得出List是O(n)、Vector是O(1)，但追问"Spark shuffle后的数据为什么常用Array而不是Vector"，就卡壳。
答案是内存布局连续性。JVM的Array在堆上连续存储，配合Tungsten的二进制序列化能直接操作堆外内存；Vector的树形结构虽然理论复杂度好，但指针跳转多、缓存不友好。这种"语法层选A，执行层选B"的权衡，是高级岗位的区分度所在。
函数式编程部分，重点考引用透明性和副作用隔离。Spark的闭包清理机制会把任务序列化到执行节点，如果闭包里包了外部可变状态，序列化要么失败，要么行为诡异。能举出var在闭包里引发Task not serializable的具体案例，比背概念管用十倍。
第四关：并发与并行——从JVM到集群的语义断层
Scala的Future、Promise、Akka Actor和Spark的分布式任务调度，共用"异步"这个词，但故障模型完全不同。面试常在这里设套。
题目21-30涉及Future的回调地狱vs for-comprehension、ExecutionContext的线程池配置、Actor的消息传递保证。关键区分点：JVM内的Future失败会抛异常，Spark的task失败会触发重试和推测执行（speculative execution）。
一个进阶考点：SparkContext的线程安全性。SparkSession和SparkContext都不是线程安全的，但Dataset的转换操作是惰性的、线程安全的。能在代码层面解释清楚这个设计——为什么提交job的入口要单线程，而定义DAG可以并行——说明真读过源码。
题目还覆盖了volatile、@transient、自定义序列化。Spark的org.apache.spark.serializer接口允许替换Kryo或Java序列化，但case class的@transient字段在executor反序列化后为null，这个行为和被lazy修饰后的区别，是生产debug的常见盲区。
第五关：类型系统与元编程——通往架构师的窄门
最后20题进入深水区：类型边界、路径依赖类型、宏（macro）、反射。这部分答不好不扣分，答好了能翻盘。
类型边界（upper/lower bound）在Spark SQL的Encoder推导里随处可见。Dataset[T]的T需要满足Encoder[T]的隐式约束，这个约束本身用到了类型边界。能解释清楚:>:和<:在协变/逆变场景的区别，说明类型理论过关。
路径依赖类型是Scala区别于Java泛型的核心特性。spark.sql.Dataset和spark2.sql.Dataset是不同的类型，即使包结构相同。这种设计让Spark 2.x到3.x的迁移可以并行维护，但也给反射-based的框架（如某些ORM）带来麻烦。
元编程部分，题目涉及scala.reflect和Scala 3的inline、quoted。Spark的Dataset的selectExpr用字符串做列选择，类型不安全；typed select用宏在编译期生成列引用，牺牲了一点灵活性换取安全。能对比这两种API的设计取舍，面试基本收尾。
最后一题是开放性的：给定一个生产OOM的Spark作业，如何用Scala的工具链定位？期望的答案是组合——jmap看堆直方图、jstack抓线程、spark-ui看stage划分，以及用Scala的sys.process或ammonite写快速脚本分析日志。
这50道题的完整答案集，某硅谷独角兽的面试官用了三年迭代。他们的反馈是：能完整答对35题以上的候选人，入职后写出的Spark代码，review通过率比平均水平高40%。你觉得自己能过哪条线？
热门跟贴