在前面的分享中，我们已经建立了对“显式依赖注入”的深刻认同。现在，我们面临最关键的架构决策：如何组织我们应用的导航逻辑？我们是应该改良现有的Router模式，还是全面转向Coordinator?

看看在现代化的声明式UI范式下，DI的思想是如何演进和应用的。这对于我们组内同时拥有Swift和Flutter技术栈的同学来说，尤其有价值。

**依赖注入（DI）是一种设计思想，而不是某一个特定的工具或框架。** 理解了这一点，我们就能在不同的场景下，选择最恰当的方式来实现解耦，而不是一味地追求“上容器”。

一个好的DI容器能帮我们自动管理对象的创建和生命周期，把我们从繁琐的手动组装中解放出来。现在一起学习业界著名框架 Swinject.

从今天起，我们将开启一个全新的技术分享系列——深入浅出依赖注入。我希望通过这个系列，能和大家一起探讨如何编写出更健壮、更灵活、更易于测试的代码。

依赖注入（以下简称 DI ）指的是为一个对象添加实例变量。 以我之见，完整的故事会稍微复杂一点。但是如果你把问题拆解到根本，你会发现实现 DI 很简单，就如同给对象添加实例变量一样。没有开玩笑，很多开发者其实把 DI 用错了地方。 💉 学习 DI 无关乎实现细节，只关乎你如何…

本文将从理解 DI 的理念讲起，到深入分析 Factory 框架的源代码。探讨 DI 思想、一种解决问题的方法，探讨 Swift 的现代 Di 架构理念，并补充其中涉及的其他内容。

前言：别再问“它跑在哪个线程？” 在 GCD 时代，我们习惯用 DispatchQueue.global(qos: .background).async { ... } 或 DispatchQueue

一、Swift 5.0（2019） 1. Result 类型 解决的问题：统一处理同步/异步操作的成功或失败状态，替代传统回调嵌套。 用法详解： 2. @dynamicCallable 协议 作用：让