BLoC vs Riverpod：命令式系统 与 声明式系统的两条架构路线
很多人把 BLoC 和 Riverpod 当成“两个 Flutter 状态管理框架”来选。
但当项目复杂到一定程度，你会发现：👉 这根本不是“库选型问题”，而是系统建模路线选择问题。
更准确地说：
BLoC 和 Riverpod，代表了两种非常典型的系统设计思想：
命令式系统 vs 声明式系统。
一、先跳出 Flutter：什么是“命令式 vs 声明式”
在软件工程中，一个非常经典的区分是：
命令式（Imperative）：我告诉系统“发生了什么、要做什么”
声明式（Declarative）：我告诉系统“关系是什么、结果应当是什么”
🌱 命令式系统关心的是：
- 发生了什么？
- 系统该执行什么动作？
- 状态如何一步步演进？
🌱 声明式系统关心的是：
- 谁由谁决定？
- 这个结果依赖哪些输入？
- 当输入变化，结果自然该变化
UI 世界里我们熟悉的是：
- 命令式 UI：手动操作 View
- 声明式 UI：描述 UI 结构
但在状态管理和架构层面，同样存在这两条路线。
二、Riverpod：典型的“声明式系统”
Riverpod 的核心不是“事件”，而是：
👉依赖关系
final totalPriceProvider = Provider((ref) { final items = ref.watch(cartProvider); final coupon = ref.watch(couponProvider); return calc(items, coupon); });你在这里没有说“什么时候更新 totalPrice”，
你只是声明了一个关系：
totalPrice = f(items, coupon)
剩下的事情全部交给系统：
- items 变 → totalPrice 自动变
- coupon 变 → totalPrice 自动变
- 没人用 → 可以回收
- 上游替换 → 下游自动重建
👉 这是一个声明式依赖系统。
你描述的是：
“这个东西由这些东西决定。”
而不是：
“当这个变了你要去改那个。”
Riverpod 的系统风格
变化来自：上游节点变化
系统核心：依赖图
程序员角色：声明关系
系统角色：负责传播
非常像：
Excel 公式系统
React / Compose 状态派生
DI 容器 + 响应式引擎
👉 这是声明式路线。
三、BLoC：典型的“命令式系统”
BLoC 的核心不是“谁依赖谁”，而是：
👉发生了什么
bloc.add(SubmitOrder()); bloc.add(Refresh()); bloc.add(DeviceDisconnected());系统的所有变化，都必须通过：
👉事件（Event）
Bloc 做的事情是：
(当前状态, 收到事件) -> 新状态
你必须显式写清楚：
- 有哪些事件
- 有哪些状态
- 每个状态下收到某事件会发生什么
👉 这是一个事件驱动状态机。
你描述的是：
“系统经历了什么，它因此走到了哪一步。”
而不是：
“这个值由谁算出来。”
BLoC 的系统风格
- 变化来自：显式事件
- 系统核心：状态机
- 程序员角色：设计流程
- 系统角色：执行迁移
非常像：
- Redux / MVI
- 协议状态机
- 工作流引擎
- 后端事件驱动系统
👉 这是命令式路线。
四、把差别说透：不是“写法”，是“控制权”
真正的差别在于：
👉系统变化由谁主导。
Riverpod：
数据变了 → 系统自动推导后果
你交给系统的是“关系”，
系统掌控的是“变化传播”。
BLoC：
发生了什么 → 系统执行对应行为
你交给系统的是“事件”，
你自己掌控的是“演进规则”。
这正是命令式 vs 声明式在系统层面的体现。
五、选型不是二选一，而是“你在解决什么问题”
更偏 Riverpod 的场景
- 派生状态多
- 数据联动强
- 依赖复杂
- 生命周期复杂
- 资源型系统（repo / cache / service）
👉 本质是结构问题。
更偏 BLoC 的场景
- 状态阶段多
- 流程复杂
- 异常分支多
- 行为必须可推理
- 协议 / 设备 / 业务流
👉 本质是行为问题。
六、成熟架构里最常见的组合
现实项目里，最常见、最稳的结构往往是：
Riverpod —— 管系统结构 / 资源 / 依赖 BLoC —— 管业务流程 / 页面行为 / 状态机也就是：
👉 Riverpod 解决“系统怎么连起来”
👉 BLoC 解决“系统怎么走下去”
七、把这条认知线拉回你最初的直觉
你说：
它们有点像命令式 UI 和声明式 UI
这个直觉是完全正确的，只是层级更高：
👉 不是 UI 写法层
👉 是系统建模层
你感受到的，其实是：
👉控制权从“人”交给“系统” vs 从“系统”交回“人”