Swift宏使用导致其他代码未执行的场景排查

1. 宏内部带提前终止逻辑 #

要是你的unwrap宏展开后是类似guard let greeting = greeting else { fatalError("空值") }这种代码，先调用它的话，要么把可选值解包成非可选变量，要么直接终止程序。后面的#unwrapNotEmpty(greeting)拿到的已经是解包后的非可选值，空值检查自然触发不了——毕竟变量已经不是可选类型了，宏里的空值判断逻辑直接没用。

2. 宏导致变量遮蔽 #

如果unwrap宏展开时创建了同名局部变量，比如let greeting = greeting!或者guard let greeting = greeting else { ... }，会把原来的可选值给遮蔽掉。后续#unwrapNotEmpty(greeting)处理的是这个已经解包的变量，不是最初的可选值，所以不会触发空值错误。这种遮蔽是宏展开后容易忽略的隐性问题，毕竟编译期展开的逻辑，作用域和原生代码一致，但开发者容易没注意到宏内部的变量绑定。

3. 编译期优化导致逻辑短路 #

有些宏会用Swift的编译期条件判断跳过逻辑，如果unwrap宏在编译期通过静态分析判定变量非空，可能直接生成解包后的代码，编译器会把后续unwrapNotEmpty的空值检查逻辑优化掉。不过这种情况大多出现在编译期能确定值的常量，动态变量很少碰到。

4. 错误处理优先级导致提前终止 #

如果unwrap和unwrapNotEmpty都有错误抛出逻辑，但unwrap用了fatalError这类直接终止程序的处理，那先调用unwrap的话，程序直接停了，unwrapNotEmpty根本没机会执行。这就解释了单独调用unwrapNotEmpty能触发错误，但一起调用时看不到的情况。

内容的提问来源于stack exchange，提问作者naljin