1. 静态派发（Static Dispatch）的性能冲突
Swift 的核心优势之一是执行效率。为了追求极致性能，Swift 编译器会尽可能使用静态派发或 vtable（函数表）派发。
- 冲突点：Swizzling 必须依赖 Objective-C Runtime 的 消息派发（Message Dispatch） 机制。
- 后果：如果你想让一个 Swift 方法支持 Swizzling，你必须给它标记
@objc dynamic。这会强制编译器放弃高效的静态优化，转而使用性能较慢的objc_msgSend。官方不希望开发者为了“黑魔法”而牺牲 Swift 带来的原生性能红利。
2. 违反“类型安全”与“编译时检查”
Swift 是一门**类型安全（Type-Safe）**的语言，强调“所见即所得”。
- 隐患：Swizzling 是典型的运行时行为。你在代码里看到调用的是
methodA，运行阶段却莫名其妙执行了methodB。 - 后果：这种不确定性会导致编译器无法在编译阶段捕捉到潜在的错误。如果在 Swizzling 过程中参数类型或返回值处理不当，会产生难以调试的崩溃，这违背了 Swift “让错误发生在编译期”的设计初衷。
3. Swift 类的结构差异
Swift 并不是 Objective-C 的简单升级，它的底层内存布局完全不同。
- 纯 Swift 类：不继承自
NSObject的纯 Swift 类根本没有isa指针，也没有method_list。这类方法直接通过地址调用，物理上不支持 Swizzling。 - 值类型：Swift 大量使用
struct和enum。这些值类型的方法在编译时就已经内联（Inline）或静态确定了，Swizzling 对它们完全无效。官方不推荐一种只能覆盖“部分场景（仅限 NSObject 子类）”的技术。
4. 写死在代码中的“不可预测性”
Swizzling 具有全局性。一旦你在某个模块执行了交换，整个 App 都会受影响。
- 维护噩梦：在大型 Swift 项目中，过多的 Swizzling 会导致逻辑链条断裂。尤其是 Swift 的扩展（Extension）不支持重写方法，如果大家都在 Extension 里乱用 Swizzling，会导致方法调用逻辑彻底混乱，变成无法追踪的“面条代码”。
5. 官方推荐的替代方案
Apple 认为，大多数需要 Swizzling 的场景，在 Swift 中都有更优雅、更安全的实现方式：
| 场景 | 替代方案 | 优点 |
|---|---|---|
| 埋点统计/日志 | 面向切面协议 (Protocol Extensions) | 类型安全，逻辑清晰 |
| 功能扩展 | 组合 (Composition) 或 装饰器模式 | 符合设计模式，易于单元测试 |
| 模拟测试 | 依赖注入 (Dependency Injection) | 彻底消除对 Runtime 劫持的依赖 |
| 动态行为 | 闭包 (Closures) 回调 | 显式的逻辑流，便于追踪 |
总结：哲学差异
- Objective-C 像是一个动态剧场：剧本（方法实现）可以随时在后台被换掉，演员（对象）根据最新的指令表演。
- Swift 像是一部精密仪器：零件（方法）在出厂（编译）时就已经精准啮合。虽然你可以强行拆解并加装转换器（Swizzling），但这不仅费力，还会破坏原有的精密平衡。
