Swift 宏在编译的语义分析阶段被扩展，具体是在解析之后，但在对最终抽象语法树（AST）进行类型检查之前。这一时间节点至关重要，因为它允许宏扩展生成的代码仍需经过完整的类型检查和语义验证。通过在这个阶段操作，Swift 确保扩展的代码不会违反语言的类型安全保证或绕过访问控制修饰符。
问题在于宏通过生成新的语法节点来转换源代码，这可能会引入与周围词法范围内现有变量冲突的标识符。如果宏只是简单地注入硬编码的变量名，它可能会意外捕获或遮蔽来自调用上下文的变量。这将导致微妙的错误或安全漏洞，其中生成的代码干扰了调用者的逻辑。
为了解决这个问题，Swift 采用了一种卫生宏系统，使用独特的内部标识符为所有合成绑定。编译器将元数据附加到语法节点，跟踪它们的原始词法上下文，确保生成的标识符在显式展开之前被视为与用户编写的代码不同。这一机制允许宏安全地引入临时变量，而无需担心名称冲突，同时在需要时也允许通过显式参数传递进行有意的名称捕获。
我们的团队正在构建一个用于依赖注入的 Swift 包，使用了一个名为 @Injectable 的附加宏，自动生成复杂服务类的初始化代码。宏需要创建临时变量来在构造期间保存中间依赖项，但我们面临着风险，像 container 或 service 这样的常见变量名可能已经存在于目标类范围内。这导致了一个困境：我们如何生成安全的初始化代码，而不冒名称冲突的风险，这将破坏客户端代码或引入微妙的重新分配错误？
我们最初考虑实现一种简单的基于文本的代码生成方法，使用简单的字符串模板来产生初始化实现。主要优点是实现简单，因为我们可以立即检查生成的 Swift 代码并直接调试它。然而，关键的缺点是缺乏卫生保障；没有机制可以确保临时变量名称不会与目标类中现有的属性冲突，从而可能导致编译失败或在宏意外重新分配现有实例变量时安静的逻辑错误。
然后我们评估了使用 Sourcery，这是一个成熟的第三方代码生成工具，在 Swift 编译器外部作为预编译步骤运行。优点包括广泛的文档、灵活的模板和能够生成整个文件而不仅仅是内联代码。但是，缺点在于复杂的构建工具集成需要在 Xcode 中进行额外的 Run Script 阶段，由于外部过程的开销，构建时间显著变慢，且缺乏实时语义分析，这意味着生成代码中的类型错误仅在编译时浮出水面，且与原始宏调用之间没有明确的源映射。
最终，我们选择了在 Swift 5.9 中引入的 Swift 原生宏系统，利用一个附加到服务类声明的同伴宏。这个解决方案之所以被选中，是因为它直接集成到编译器管道中，提供对扩展代码的编译时类型检查，并通过 SwiftSyntax 库为生成的标识符提供内置的卫生保障。结果是一个健壮的依赖注入框架，其中 @Injectable 宏可以安全地生成复杂的初始化逻辑，而不必担心名称遮蔽，使样板代码减少约 70%，同时保持完整的编译时安全保障和指向宏使用位置的清晰错误信息。
最终实现消除了我们之前手动依赖注入设置中困扰的整个类别的命名相关错误。与 Sourcery 方法相比，构建时间提高了 40%，开发者可以自信地重构服务类，因为宏生成的初始化器会自动适应新的依赖项，而无需手动同步。
为什么 Swift 中的宏不能就地修改现有代码，哪些替代模式能够实现类似的语义？
与可以就地转换现有语法节点的 Lisp 或 Rust 程序宏不同，Swift 宏是纯粹的附加——它们只能生成新代码，而不能改变原始源。这一限制的存在是因为 Swift 的编译模型要求原始源保持完整，以便进行调试、源映射和增量编译。为了实现“修改”语义，开发者必须使用同伴宏生成额外的重载或包装类型，并在原始声明上添加弃用注释，以引导迁移到生成的替代品。
宏扩展如何处理生成表达式的类型推断，当推断失败时会发生什么？
当宏扩展为包含没有显式类型注解的表达式的代码时，Swift 在宏扩展之后的标准类型检查阶段对生成的 AST 执行类型推断。如果推断失败，编译器会发出诊断消息，将错误位置映射回宏调用位置，使用在扩展期间附加的源位置元数据。候选人常常忽略宏可以显式生成 #file 和 #line 字面值，或使用 #sourceLocation 指令来控制诊断如何呈现给用户，确保错误指向有意义的位置，而不是内部宏实现细节。
独立宏和附加宏在扩展上下文和可用语义信息方面有什么区别？
独立宏（前缀为 #）在表达式或语句级别扩展，并有限制地访问周围的类型信息，仅接收其参数的语法。相反，附加宏（前缀为 @）操作于声明并接收丰富的语义信息，包括附加声明的语法、访问修饰符和通过 macro 声明的上下文参数继承关系。初学者常常混淆这些边界，尝试在需要访问类型成员或在特定类型范围内生成嵌套声明的位置上使用独立宏，而实际上需要附加同伴或成员宏。