SwiftUI如何基于UserDefaults存储的用户凭据创建可复用HTTP连接

AWS SDK中的AWSClient是持有底层TCP连接、线程池资源的引用类型，需要在实例废弃前主动调用syncShutdown()释放资源，之前遇到的两类运行时断言问题，本质是没有给客户端匹配到正确的生命周期挂载点，按照以下架构拆分即可彻底解决耦合和资源释放问题：

1. 纯职责拆分：让用户配置类回归定位 #

专门存用户访问密钥、私密密钥、地域的ObservableObject只做配置的持久化读写，完全不接入任何AWS客户端逻辑：

• 类内部仅负责将用户输入的配置序列化存入UserDefaults，App启动时从本地读取配置完成初始化，当配置发生变更时向外发变更通知即可。
• 从根源上避免把客户端逻辑和用户配置类耦合的问题，哪怕之前硬编码场景能在配置类的deinit中手动调用shutdown，这种写法也会让配置类承担不属于它的资源管理职责，后续维护成本极高。

2. 独立资源管理类：集中持有并管理AWSClient生命周期 #

新建一个专门负责AWS资源调度的ObservableObject，作为全局单例被注入SwiftUI视图树，专门承接AWSClient的创建、更新、释放全流程：

• 类内部用持久化存储属性持有当前可用的AWSClient实例，绝对不要用计算属性：计算属性每次访问都会新建无引用的临时客户端，根本追踪不到引用节点自然没法触发shutdown。
• 初始化时订阅用户配置类的变更通知：当用户修改了访问密钥、地域这类影响客户端连接的核心配置时，先对旧的客户端实例同步调用syncShutdown()完成资源释放，再基于新的配置创建新的客户端实例赋值给存储属性。
• 监听App全局的终止通知，在App即将退出的节点，在类内部统一调用当前持有的客户端的syncShutdown()，彻底规避反初始化时未关闭客户端的运行时断言。
• 所有面向S3、EC2等服务的REST请求逻辑，全部封装在这个类的公开方法里，比如listS3Buckets()、describeEC2Instances()，视图层完全不需要接触客户端实例本身。

3. 跨视图复用的链路打通 #

把这个资源管理类作为EnvironmentObject注入到App的根视图节点：

• 所有需要调用AWS接口的子视图，直接通过环境变量拿到管理类实例，调用它暴露的封装方法即可发起请求，完全不需要在视图的辅助函数里临时创建客户端——SwiftUI视图是无deinit能力的结构体，临时创建的客户端没有有效持有方做优雅关闭，必然触发资源泄漏的断言。
• 管理类可以对外暴露isClientReady这类计算属性，视图可以根据客户端的初始化状态动态渲染引导输入、加载态、正常业务页面，不需要单独做客户端状态的判断逻辑。

之前两种错误实现的问题根源：

• 将AWSClient作为计算属性放在用户偏好类中：没有固定的实例持有引用，根本找不到合适的时机调用shutdown
• 在视图辅助函数中临时创建客户端：视图作为值类型没有反初始化能力，临时实例永远等不到优雅关闭的触发节点

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