对象层级间共享状态是否存在更符合Combine范式的实现方式？

你当前的实现可以运行，但存在3个不符合Combine设计哲学、容易埋下隐患的问题：

• 权限完全裸奔：CurrentValueSubject直接暴露给所有子对象，意味着任何持有方都可以随意发送值、读取当前值，没有任何边界控制，后续要加状态校验、修改审计逻辑时需要改动所有持有对象的代码
• 订阅存在隐式失效风险：sink返回的AnyCancellable没有被存储，订阅会在初始化方法执行完成后立刻被释放，你现在感知到“正常运行”只是刚好生命周期巧合，一旦触发内存回收就会出现订阅不触发的问题
• 耦合度过高：子对象强依赖CurrentValueSubject这个具体类型，后续如果要替换状态源（比如换成数据库观察流、网络推送流），所有子对象的初始化逻辑都要修改

符合Combine惯用范式的实现 #

核心原则是用类型系统做读写权限隔离，统一管理订阅生命周期，对上层隐藏具体实现细节，优化后的代码如下：

import Combine

// 业务侧共享状态模型，根据实际需求定义属性
struct SharedState {
    var count: Int = 0
    var contentTitle: String = ""
}

class Child {
    // 持有只读的状态发布者，无法直接发送值
    private let stateStream: AnyPublisher<SharedState, Never>
    // 持有状态修改入口，仅通过暴露的方法更新状态
    private let mutateState: (inout SharedState) -> Void
    // 管理当前类的所有订阅，生命周期与实例绑定
    private var cancellables = Set<AnyCancellable>()

    init(
        stateStream: AnyPublisher<SharedState, Never>,
        mutateState: @escaping (inout SharedState) -> Void
    ) {
        self.stateStream = stateStream
        self.mutateState = mutateState

        // 订阅状态变化，弱引用self避免循环引用
        stateStream
            .sink { [weak self] currentState in
                self?.handleStateUpdate(currentState)
            }
            .store(in: &cancellables)
    }

    private func handleStateUpdate(_ state: SharedState) {
        // 业务侧状态响应逻辑
        print("子组件收到状态更新，当前count：\(state.count)")
    }

    // 子组件主动更新状态的示例方法
    func triggerCountIncrement() {
        mutateState { state in
            state.count += 1
        }
    }
}

class Parent {
    // 私有持有真实的Subject，仅内部可直接访问
    private let stateSubject: CurrentValueSubject<SharedState, Never>
    // 对外暴露只读的状态流，所有外部观察者只能订阅不能直接发值
    var sharedState: AnyPublisher<SharedState, Never> {
        stateSubject
            .receive(on: DispatchQueue.main) // 统一指定回调线程，避免子线程更新UI
            .removeDuplicates() // 相同状态不重复触发回调
            .eraseToAnyPublisher()
    }

    let child1: Child
    let child2: Child

    init() {
        let initialState = SharedState()
        let subject = CurrentValueSubject<SharedState, Never>(initialState)
        self.stateSubject = subject

        // 统一封装状态修改逻辑，后续加校验、埋点只需要改这一处
        let stateMutation: (inout SharedState) -> Void = { change in
            var current = subject.value
            change(&current)
            subject.send(current)
        }

        self.child1 = Child(
            stateStream: subject.eraseToAnyPublisher(),
            mutateState: stateMutation
        )
        self.child2 = Child(
            stateStream: subject.eraseToAnyPublisher(),
            mutateState: stateMutation
        )
    }

    // 父组件主动更新状态的示例方法
    func updateTitle(_ newTitle: String) {
        stateSubject.value.contentTitle = newTitle
    }
}

方案优势 #

• 权限管控清晰：真实的状态源仅父对象可访问，只读组件只拿发布者、可写组件只拿修改入口，从语法层面避免随意篡改状态的问题
• 生命周期安全：每个实例自己管理订阅集合，订阅会跟随实例释放自动取消，不会出现提前失效的问题；sink闭包用弱引用持有self，不会产生循环引用
• 耦合度极低：子对象不需要关心状态源的具体实现，不管底层是CurrentValueSubject、数据库观察流还是网络推送流，只要输出SharedState类型就能直接接入
• 易维护：所有状态流的统一处理（线程切换、去重、日志、错误兜底）都可以在父对象暴露sharedState的位置统一配置，所有订阅方自动生效，不需要重复写逻辑

额外注意事项 #

• 如果某个子对象只需要读状态、不需要修改，初始化时只传stateStream即可，不要传入修改闭包，从参数层面做能力限制
• 不要在订阅回调里做耗时操作，避免阻塞状态分发
• 如果需要针对特定场景做状态切片（比如某个子对象只关心count字段的变化），可以在订阅时单独加map、removeDuplicates算子，减少无效回调

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