问题的回答
Swift的并发模型在6.0版本中经历了显著的增强，推出了严格的数据隔离要求，跨模块边界扩展。当一个使用严格并发检查编译的模块调用一个标记为**@preconcurrency的旧版模块时，编译器不能仅依赖静态分析来保证安全，因为被调用者的实现可能早于actor的隔离保证。为了弥补这一差距，Swift在函数的类型信息和见证表中嵌入了隔离要求作为元数据，通过不改变调用约定或符号修饰来保持ABI稳定性。在运行时，生成的代码使用swift_task_isCurrentExecutor内部方法进行动态检查，以验证当前任务是否在所需的全局actor**的串行执行器上执行；如果检查失败，任务将异步排入正确的执行器，或者根据构建配置触发诊断崩溃。
生活中的情况
一个金融科技团队维护了一个用Swift 5.9编写的老旧分析SDK（模块B），该SDK在后台线程上执行重的统计计算，但偶尔通过完成处理程序发布UI更新。当他们在新的消费银行应用（模块A）中采用Swift 6时，他们需要保证所有UI更新都发生在MainActor上，而无需立即重写整个SDK。他们考虑了三种方法来解决隔离边界问题。
第一种选择是对SDK进行同步重写，以在整个代码中采用Swift 6的actors和Sendable类型。虽然这将提供编译时安全性且没有运行时开销，但工程成本是不可承受的——预计需三个月，并在关键计算逻辑中引入高回归风险。第二种选择是手动在模块A中的调用点将每个SDK回调包装在DispatchQueue.main.async中。这种方法是明确的，并且不需要SDK更改，但它产生了脆弱、分散的模板代码，容易被遗漏，从而在新开发者添加功能时导致潜在的数据竞争。第三种选择是在SDK的公共接口上使用**@preconcurrency注释，并结合MainActor**隔离要求。
团队选择了第三种解决方案，为旧的回调添加了@preconcurrency @MainActor注释。这允许模块A调用这些方法，并确保Swift运行时将在过渡期间动态验证执行器上下文。当发生违规时——例如，一个后台线程尝试调用一个UI回调——应用在调试构建中立即崩溃，并提供清晰的诊断，使开发者能够逐步识别和修复线程假设。一旦SDK完全迁移到严格并发，他们便移除了**@preconcurrency**，以仅强制执行静态隔离，从而产生一个没有运行时隔离检查且保证线程安全的代码库。
候选人常常忽略的内容
@preconcurrency如何影响ABI中函数的修饰符号名称，这对动态链接有什么重要性？
@preconcurrency不会改变函数的修饰符号名称或低级调用约定，因为隔离要求被编码在类型元数据和见证表中，而不是在符号本身。这种设计对于ABI的稳定性至关重要，因为它允许库作者向现有公共API添加actor隔离，而不会破坏与先前编译的客户端的二进制兼容性。动态检查由编译器根据元数据在调用点或入口点注入，确保老旧的二进制文件能够无缝链接到更新的、具有隔离意识的库。
全局actor的shared实例声明为let与var之间有什么区别，这对执行器的唯一性有何影响？
GlobalActor协议要求一个静态的shared属性返回底层的actor实例，并且该属性必须声明为let常量，以保证单一的、进程范围内的唯一串行执行器。如果shared是一个var，理论上执行器可以在运行时被交换，这会违反全局actor提供单一串行队列用于所有隔离操作的基本不变性，可能导致数据竞争并破坏隔离边界。Swift编译器通过要求shared为静态不可变属性来强制执行这一点，从而确保swift_task_isCurrentExecutor始终与一致的单例执行器对象进行比较。
当一个函数被隔离到一个全局 actor 时，为什么编译器有时会在同一个 actor 内部调用时发出跳转到执行器的指令，以及isolated参数修饰符如何优化这一点？
当编译器无法静态证明调用者已经在目标全局actor的执行器上执行时，它会发出执行器跳转——或者至少进行运行时验证，这种情况通常发生在跨模块边界或通过存在类型调用时，其中隔离信息被擦除。这种保守的方法确保安全性，但会产生同步开销。开发者可以通过使用isolated参数修饰符（例如，func process(isolation: isolated MainActor = #isolation)）来优化这一点，它明确地将调用者的隔离上下文作为参数传递；这允许编译器在调用者证明它处于同一执行器上时省略运行时检查和跳转，从而将调用简化为直接函数调用，而没有上下文切换的成本。