1. 从 setState 到数据流：Flutter for OpenHarmony 为什么需要 StreamBuilder
先说一个很实际的场景。你辛辛苦苦把 Flutter 工程跑到了 OpenHarmony 设备上，界面起来了，基础组件也都能用，然后开始写业务逻辑。这时候遇到最普遍的需求，就是页面要实时响应数据变化——比如传感器数据、消息推送、下载进度、多页面之间的状态同步。很多开发者的第一反应是setState一把梭，局部刷新嘛，简单直接。但真到了数据来源多、刷新频率高、页面层级深的场景，你就会发现setState根本撑不住，代码开始变得拧巴，各种状态不同步、Widget 不必要的重建、性能肉眼可见地往下掉。
StreamBuilder 解决的就是这个问题。它不是 Flutter 里新出的东西，而是 Dart 原生Stream机制在 Widget 层的封装，通过响应式数据流的方式把“数据到达”和“界面更新”解耦。数据的生产者只需要往 Stream 里塞数据，StreamBuilder 监听到新事件后自动触发 rebuild，整个过程不需要手动管理状态、不需要监听器注册销毁、也不用手动控制刷新时机。这套机制放到 OpenHarmony 的 Flutter 环境里，意义更大。因为 OpenHarmony 的设备形态千差万别，从轻量级 IoT 设备到富媒体终端都有，底层系统的线程调度、资源约束和 Android/iOS 不太一样，数据流的异步处理方式如果设计得不好，很容易出现丢消息、界面卡顿甚至渲染异常。
所以这篇文章我不打算讲 StreamBuilder 的 API 参数有多全——那些官方文档里都有。我重点想聊的是，在 Flutter for OpenHarmony 这个具体环境下，StreamBuilder 怎么用才能真正解决业务问题，哪些坑是平台特有的，以及响应式数据流的架构思路怎么落地。无论你是刚开始接触 OpenHarmony 上的 Flutter 开发，还是已经做了几个业务模块想优化状态管理，这篇文章都值得花十分钟看完。
2. 核心思路拆解：StreamBuilder 的运作机制与 OpenHarmony 适配要点
2.1 Stream 与 StreamBuilder 的关系，理解这层才算入门
很多人一开始搞混 Stream 和 StreamBuilder，以为它们是同一个东西。实际上一个是数据管道，一个是 UI 组件，二者通过订阅关系连接。Stream 负责异步产生数据序列，可以类比成一条传送带，上游往传送带上放东西，下游按顺序接收。StreamBuilder 则是传送带尽头的一个显示器，只要有新东西到货，它就把货展示出来。
具体到代码层面，StreamBuilder 的核心构造参数就三个：stream指定要监听的数据源，initialData设置首帧数据避免空屏，builder根据AsyncSnapshot的状态返回不同的 Widget。当 Stream 发出新事件时，StreamBuilder 内部会调用setState触发重建，这等于框架帮你把状态管理和界面刷新都包办了。
StreamBuilder<T>( stream: _controller.stream, initialData: _initialValue, builder: (context, snapshot) { if (snapshot.hasError) { return ErrorWidget(snapshot.error.toString()); } if (!snapshot.hasData) { return const LoadingWidget(); } return ContentWidget(snapshot.data!); }, )这里有一个关键点，很多文章一笔带过但实际影响很大：StreamBuilder 在每次重建时都会重新订阅 Stream。如果 Stream 是单订阅（single-subscription）类型，第二次订阅会直接报错 “Stream has already been listened to”。所以业务开发里，我基本只用广播型 StreamController，也就是StreamController.broadcast()，它允许多个监听者同时存在，哪怕页面在 rebuilding 过程中订阅关系重建也不会炸。
2.2 OpenHarmony 环境下的异步调度差异，不能照搬 Android 经验
Flutter for OpenHarmony 的底层引擎把 Dart 的Isolate和事件循环跑在 OpenHarmony 的能力层之上，整体模型和标准 Flutter 一致，但具体到异步任务的调度策略、线程优先级、系统资源回调上，跟 Android 和 iOS 并不完全一样。我在真机上调试时发现，如果在 OpenHarmony 上同时开多个 Stream 高频产生事件，或者配合Future.delayed、Timer.periodic这类定时任务一起用，偶发会出现事件延迟甚至丢失的现象，后来定位到是底层任务分发节奏和 UI 渲染帧率没对上。
这不是说 Stream 机制在 OpenHarmony 上有 bug，而是说你得主动控制数据流的节奏。具体的做法我会在后面“实操过程”里详细展开，这里先提一个核心原则：Stream 的产出频率尽量不要超过 UI 刷新所需的最低帧率，必要的场景要加节流或合并缓冲。
另外，OpenHarmony 对 Flutter 的插件通信走的是平台通道（Platform Channel），通道返回结果默认也是异步的。如果你把平台通道的返回值再塞进 Stream，实际上链条就变成“原生事件 → 平台通道 → Dart Stream → StreamBuilder”，每一跳都有上下文切换成本。测试下来，从 OpenHarmony 原生侧发一个高频事件到 UI 刷新，端到端延迟大概在几毫秒到十几毫秒不等，低端设备上波动更大。所以对于实时性要求极高的场景（比如手势轨迹、音频波形），建议走 Texture 或者直接渲染层，别硬套 Stream；但对于绝大多数业务数据（消息、进度、状态变更），StreamBuilder 完全够用，而且代码干净得多。
2.3 为什么 StreamBuilder 适合 OpenHarmony 多设备形态的业务
OpenHarmony 的设备覆盖面很广，手机、平板、电视、车机、带屏 IoT 设备都可能跑 Flutter。在多设备场景下，一个页面可能需要同时监听多个数据源——比如一个远程控制页面，既要监听设备状态通道，又要监听网络连接状态，还要监听用户操作事件。用传统setState写，你得在initState里注册一堆回调，在dispose里挨个注销，漏一个就出内存泄漏或崩溃。用 StreamBuilder，每个数据源独立成一个 Stream，页面组件各自订阅，生命周期自动管理，代码结构天然就是解耦的。
而且 StreamBuilder 和 OpenHarmony 的分布式软总线结合时，有一个天然优势：软总线的数据回调本质上是事件驱动，把事件包装成 Stream 数据流，上游无论来自本地传感器还是远端设备，对 UI 层来说没有区别。这样业务代码不关心数据从哪来，只关心 Stream 里有没有新数据，界面层做到了完全的数据驱动。
3. 核心细节与实操要点：响应式数据流的设计和开发技巧
3.1 从零搭一个响应式Stream管理器，解决跨组件通信
实际项目里，Stream 最常解决的问题不是页面内部的刷新，而是跨页面的状态同步。举个我在 OpenHarmony 平板上做的设备控制面板例子：首页显示设备列表，点击进入设备详情页后修改参数，返回列表页时列表状态必须同步更新。如果靠路由传参回传，链路长、容易漏；用全局 Stream 做事件总线，代码量最少，而且逻辑直观。
我习惯把 Stream 管理器封装成单例，而不是每个页面自己创建StreamController。全局单例的好处很明显：生命周期可控，页面销毁后数据流不会断，等页面重新创建时能拿到最新状态。放一段我实际项目里用过的简化版本：
class DataStreamManager { DataStreamManager._(); static final DataStreamManager instance = DataStreamManager._(); final _deviceStatusController = StreamController<DeviceStatus>.broadcast(); Stream<DeviceStatus> get deviceStatusStream => _deviceStatusController.stream; void updateDeviceStatus(DeviceStatus status) { if (!_deviceStatusController.isClosed) { _deviceStatusController.add(status); } } void dispose() { _deviceStatusController.close(); } }业务页面里，你只需要在initState里订阅，在dispose里取消：
StreamSubscription<DeviceStatus>? _sub; @override void initState() { super.initState(); _sub = DataStreamManager.instance.deviceStatusStream.listen((status) { setState(() { _currentStatus = status; }); }); } @override void dispose() { _sub?.cancel(); super.dispose(); }这段代码的重点不在 Stream 本身，而是listen之后的StreamSubscription一定要保存下来，在dispose里 cancel。我在 OpenHarmony 上遇到过几次页面退出后仍然收到事件导致的状态错乱，查下来基本全是订阅没取消的问题。不要指望 StreamBuilder 帮你做这件事，因为 StreamBuilder 是 Widget，它销毁时确实会取消订阅，但如果你手动listen了，框架管不着你的回调。
3.2 StreamBuilder 的 snapshot 状态机，理解它才能写出稳定 UI
StreamBuilder 的 builder 回调里拿到的AsyncSnapshot，有几个状态需要区分清楚：ConnectionState.waiting表示等待第一个事件，active表示已开始接收数据流，done表示 Stream 已关闭；配合snapshot.hasData和snapshot.hasError，组合起来就是完整的 UI 分支逻辑。
很多初学者的误区是只判断hasData，忽略了waiting和done的差异。这两个状态在 UI 表现上应该不一样：waiting 适合展示加载动画，done 适合展示“数据已加载完”的空状态或结尾标记。特别是从 OpenHarmony 平台通道拿数据时，通道刚建立时有一段天然延迟，这个窗口期就是ConnectionState.waiting，如果此时直接渲染空数据，用户会看到白屏闪烁。
更好的做法是在Stream的源头用initialData给一个合理的默认值。还是拿设备状态举例：
StreamBuilder<DeviceStatus>( stream: DataStreamManager.instance.deviceStatusStream, initialData: DeviceStatus.unknown(), builder: (context, snapshot) { if (snapshot.hasError) { return const Text('状态加载失败'); } final status = snapshot.data ?? DeviceStatus.unknown(); return _buildStatusWidget(status); }, )这样首帧就能渲染出“未知状态”的占位 UI，而不是闪一下空白再加载，体验差距非常明显。
3.3 Stream 的背压与节流，OpenHarmony 低端机上保持流畅的关键
就算 StreamBuilder 本身机制没问题，如果上游生产数据的速度远快于 UI 消费速度，就会出现背压（backpressure）问题。在 OpenHarmony 的低端设备上，这个问题会被放大。我实测过一台开发板，Dart 侧每秒钟往 Stream 里塞 100 条消息，UI 的刷新帧率只有 30fps 左右，StreamBuilder 的 rebuild 任务排队，界面肉眼可见掉帧。
解决办法有两个方向：一是降低生产速率，二是合并消费请求。生产端如果是传感器或平台通道回调，速率往往不可控，所以主要靠消费端做节流。最简单的方式是引入RxDart的debounceTime或throttleTime操作符，但如果不方便引入额外依赖，也可以自己写一个简单的节流器：
Stream<T> throttleStream<T>(Stream<T> source, Duration duration) { return source.transform( StreamTransformer.fromHandlers( handleData: (data, sink) { // 简单节流：每个时间窗口只放第一个事件 if (!_throttleActive) { _throttleActive = true; sink.add(data); Timer(duration, () => _throttleActive = false); } }, ), ); }注意，节流器的时长选择要跟业务匹配。UI 进度条更新 200ms 一次就够，设备状态刷新 500ms 一次也能接受，但如果是文本输入搜索框，300ms 的防抖更合理。不要套一个固定值到处用，不同业务场景差异很大。
4. 实操过程：OpenHarmony 上实现一个完整的响应式数据流页面
4.1 环境准备与工程创建
开始写代码之前，先把环境问题解决掉，因为这里有个很常见的坑。如果你当前用的 IDE 是 VS Code，在 Windows 上跑 Flutter 工程有时会报 “unable to find suitable visual studio toolchain” 之类的构建错误，这个不是你代码问题，是 Flutter 在 Windows 上依赖 Visual Studio 的 C++ 工具链来做 Windows 桌面端的编译。但 OpenHarmony 工程本身并不需要 Windows 桌面编译，所以在项目里把windows目录删掉或忽略掉，只在 OpenHarmony 设备上构建就行。
另外还有一个报错在升级 Flutter 后很常见：“You are applying Flutter's main Gradle plugin imperatively using the apply script”。这个是 Flutter 3 以后对新版 Gradle 插件应用方式的检查导致的。解决办法是把项目的android/settings.gradle改成插件 DSL 方式声明，而不是旧式apply。虽然 OpenHarmony 工程的构建走的是hvigor，不直接依赖 Gradle，但 Flutter 工具链在做工程初始化时仍可能触发这一检查，提前改好省得后面卡住。
工程创建用标准的 flutter 命令就行，创建完以后需要执行flutter pub get拉取依赖。如果是基于已有 OpenHarmony Flutter SDK 的项目，记得确认ohos-sdk路径配置正确，不然后续跑真机时会报找不到 SDK 的错误。
4.2 需求场景：做一个多数据源状态面板
为了把 StreamBuilder 的用法讲透，我设计了一个贴合 OpenHarmony 设备场景的 demo：一块状态面板，同时监听三个数据源——系统电池电量、网络连接状态、后台下载进度。每个数据源对应一个 Stream，页面用三个 StreamBuilder 分别渲染，互不干扰。
先定义数据模型和 Stream 管理器：
class BatteryInfo { final int level; final bool charging; BatteryInfo(this.level, this.charging); } class NetworkInfo { final bool connected; final String networkType; NetworkInfo(this.connected, this.networkType); } class DownloadProgress { final double progress; DownloadProgress(this.progress); }class StatusStreamManager { StatusStreamManager._(); static final StatusStreamManager instance = StatusStreamManager._(); final _batteryController = StreamController<BatteryInfo>.broadcast(); final _networkController = StreamController<NetworkInfo>.broadcast(); final _downloadController = StreamController<DownloadProgress>.broadcast(); Stream<BatteryInfo> get batteryStream => _batteryController.stream; Stream<NetworkInfo> get networkStream => _networkController.stream; Stream<DownloadProgress> get downloadStream => _downloadController.stream; void updateBattery(BatteryInfo info) => _batteryController.add(info); void updateNetwork(NetworkInfo info) => _networkController.add(info); void updateDownload(DownloadProgress progress) => _downloadController.add(progress); void dispose() { _batteryController.close(); _networkController.close(); _downloadController.close(); } }场景里我模拟了 OpenHarmony 设备连接分布式外设时可能出现的网络状态抖动：Wi-Fi 和蓝牙都在抢网络资源，网络类型在wifi和ble之间来回切。这个模拟数据在 Stream 里跑起来后，页面上能很直观地看到 StreamBuilder 每收到一个事件就刷新对应区块，而其它区块不受任何影响。
4.3 UI 层用 StreamBuilder 组织响应式展示
页面布局我分了三个区域，每个区域一个 StreamBuilder。这里有个细节：不要把所有数据源合并成一个 Stream 再一起监听，否则任何一个数据刷新都会导致整个页面重建，性能上和setState没区别，就失去了响应式拆分的意义。
class StatusPanel extends StatelessWidget { const StatusPanel({Key? key}) : super(key: key); @override Widget build(BuildContext context) { return Column( children: [ StreamBuilder<BatteryInfo>( stream: StatusStreamManager.instance.batteryStream, initialData: const BatteryInfo(100, true), builder: (context, snapshot) { final battery = snapshot.data ?? const BatteryInfo(100, true); return _BatteryCard(level: battery.level, charging: battery.charging); }, ), const SizedBox(height: 12), StreamBuilder<NetworkInfo>( stream: StatusStreamManager.instance.networkStream, initialData: const NetworkInfo(false, 'unknown'), builder: (context, snapshot) { final network = snapshot.data ?? const NetworkInfo(false, 'unknown'); return _NetworkCard(connected: network.connected, type: network.networkType); }, ), const SizedBox(height: 12), StreamBuilder<DownloadProgress>( stream: StatusStreamManager.instance.downloadStream, initialData: const DownloadProgress(0), builder: (context, snapshot) { final progress = snapshot.data?.progress ?? 0; return _ProgressCard(progress: progress); }, ), ], ); } }StatusPanel用StatelessWidget就够了，因为状态全在 Stream 里，组件本身不需要持有可变数据。这一点是响应式编程带来的最大改变：以前你得写StatefulWidget配合setState，现在 StatelessWidget 加上 StreamBuilder 就能搞定，代码量减少，出错面也变小。
4.4 模拟数据源，跑起来看效果
为了不依赖 OpenHarmony 的真实传感器，我用Timer.periodic模拟数据源。注意，模拟的数据节奏一定要接近真实场景，不然测不出性能问题。比如电池电量 30 秒变一次，网络状态 2 秒切一次，下载进度 200ms 更新一次。三个频率混在一起，正好考验页面在混合数据流下的稳定性。
void startMockData() { Timer.periodic(const Duration(seconds: 30), (timer) { final randomLevel = 60 + Random().nextInt(40); StatusStreamManager.instance.updateBattery(BatteryInfo(randomLevel, true)); }); Timer.periodic(const Duration(seconds: 2), (timer) { final isWifi = DateTime.now().second.isEven; StatusStreamManager.instance.updateNetwork( NetworkInfo(true, isWifi ? 'wifi' : 'ble'), ); }); Timer.periodic(const Duration(milliseconds: 200), (timer) { _mockDownloadProgress += 0.01; if (_mockDownloadProgress > 1) { _mockDownloadProgress = 0; } StatusStreamManager.instance.updateDownload( DownloadProgress(_mockDownloadProgress), ); }); }放到 OpenHarmony 真机上跑过一轮以后，整体交互是流畅的。高频的下载进度刷新会带动_ProgressCard频繁重建，但另外两个卡片不会跟着闪，说明 StreamBuilder 的监听隔离起到作用了。唯一的感受是低端设备上 200ms 一次的刷新有点激进，实际项目中拉到 300~500ms 会更保险。
4.5 平台通道接入：让 OpenHarmony 原生事件驱动 Stream
模拟数据跑通后，还要把这个架构接到 OpenHarmony 原生系统上，数据流才能真正用起来。Flutter for OpenHarmony 的插件机制跟其它平台类似，通过 MethodChannel 和原生侧通信。比如要实时监听 OpenHarmony 系统的电量变化，原生侧在电量变化回调里通过 EventChannel 或 MethodChannel 把数据发过来，Dart 侧收到后直接往对应的 StreamController 里 add。
static const _batteryChannel = EventChannel('ohos/plugins/battery/events'); void listenNativeBatteryEvents() { _batteryChannel.receiveBroadcastStream().listen((event) { if (event is Map) { final level = event['level'] as int? ?? 0; final charging = event['charging'] as bool? ?? false; StatusStreamManager.instance.updateBattery(BatteryInfo(level, charging)); } }); }这里有个经验：EventChannel 的事件流和 Stream 是天然匹配的，基本一层透传。实际使用中要注意原生侧事件回调所在的线程，如果高频事件直接从原生 UI 线程打进 Dart，配合页面自身的 rebuild 逻辑，低端机上可能引起渲染抢占。建议在原生侧对事件做一次节流或者合并，要么在 Dart 侧再做一次防抖，两种方式我都试过，更推荐在 Dart 侧处理，因为改动成本低，且不会影响原生侧对事件的完整记录。
5. 常见问题与排查技巧实录
5.1 OpenHarmony 上画面渲染异常，先查数据流节奏
之前有朋友遇到一个诡异问题：Flutter 页面跑在 OpenHarmony 开发板上，正常静止画面没问题，一旦有数据进来频繁刷新，就会出现画面撕裂、部分区域渲染异常。最初怀疑是 GPU 驱动问题，排查半天，后来发现根子是数据流频率太猛。事件生产端每 10ms 发一条消息，StreamBuilder 每收到一条就触发一次 rebuild，而低端设备的渲染管线根本消化不了这么多帧，丢帧之后画面自然怪怪的。
解决办法就是我前面说的节流。把 Stream 侧的刷新频率限制在 30fps 以内，也就是 33ms 以上一条。如果你是第三方数据源，没法控制上游频率，那就用我给的throttleStream包装一下。改完之后画面异常立刻消失，性能稳定很多。
提示：OpenHarmony 设备上的 Flutter 渲染流水线跟 Android 有差异，在低端机型上不要盲目追求高刷。数据驱动 UI 的核心是“稳”，不是“快”。
5.2 单订阅 Stream 重复监听报错，广播流才是正解
排查这类问题时，最常见的报错是：
Bad state: Stream has already been listened to.原因基本就是用了普通的StreamController而不是broadcast()。普通 StreamController 只允许一个监听者，StreamBuilder 在 rebuild 或组件复用时会重新订阅，一订阅就炸。开发阶段建议直接统一用StreamController.broadcast()，省得后续加监听列表时出问题。
另外，有些状态管理库（比如 Provider 的StreamProvider）内部也会对 Stream 做代理和转换，如果底层 Stream 不是广播类型，同样会触发重复监听问题。所以不管用什么框架，Stream 源头的类型选型一定要想清楚。
5.3 Stream 订阅了不取消，页面退出后照样收到数据
这是 Stream 编程最容易犯的错误，也是我在 OpenHarmony 上踩得最深的坑之一。页面跳转后，如果不取消订阅，全局 StreamController 还在工作，事件照样推进你的回调，此时如果回调里刚好用了BuildContext，轻则内存泄漏，重则直接崩溃，报错内容一般是“Looking up a deactivated widget's ancestor is unsafe”。
我的习惯是：所有手动listen的地方，必须成对写cancel。用StatefulWidget的话，把StreamSubscription存在成员变量里，在dispose里取消；如果是WidgetsBindingObserver这类混入式组件，也要在对应的销毁回调里处理干净。
5.4 表格：StreamBuilder 高频问题速查表
| 问题现象 | 可能原因 | 解决方式 |
|---|---|---|
| 页面白屏闪烁 | 没有设置initialData，等待期渲染了空内容 | 给 StreamBuilder 配置合理的初始值 |
| 某些数据不刷新 | Stream 事件被节流器误过滤 | 检查节流时长是否过短，业务是否对该事件敏感 |
| 页面退出后仍收到事件 | 忘了 cancel 订阅 | 在 dispose 中取消 StreamSubscription |
| 频繁掉帧、画面撕裂 | 数据流频率过高 | 对 Stream 做节流/合并，限制刷新频率 |
| Stream 重复监听报错 | 用了单订阅 StreamController | 改用broadcast()类型 |
| 断网后 UI 表现异常 | 错误流未处理 | 在 builder 里判断snapshot.hasError渲染错误 UI |
| 事件丢失 | 数据频率超过底层调度能力 | 降低投递频率或在原生侧合并事件 |
5.5 调试 Stream 数据流的两个小工具
排查 StreamBuilder 问题，光靠print效率太低，尤其在 OpenHarmony 真机上，日志刷得快，根本来不及看。我的做法是给数据流加上一个观测点，统一打印事件内容：
Stream<T> debugStream<T>(String tag, Stream<T> source) { return source.transform( StreamTransformer.fromHandlers( handleData: (data, sink) { debugPrint('[$tag] event: $data'); sink.add(data); }, handleError: (error, stackTrace, sink) { debugPrint('[$tag] error: $error'); sink.addError(error, stackTrace); }, ), ); }引入之后，把页面里监听的 Stream 都过一遍这个包装，事件流向一目了然。另外，如果页面逻辑复杂，可以用 Flutter DevTools 里的 Timeline 看看 rebuild 频率，虽然 OpenHarmony 版本的 DevTools 支持度和 Android 上有差距，但基础功能是能用的。用 Timeline 能看到每个 StreamBuilder 的 rebuild 时间点，配合调试日志，能快速定位是哪个数据源在捣乱。
5.6 Flutter 与 OpenHarmony 版本升级带来的兼容性提醒
OpenHarmony 的 Flutter 适配版一直在演进，API 层面有变动很正常。如果你遇到“跑了旧代码后新版本 SDK 上报编译错误”，先别急着改业务逻辑，优先检查是不是 SDK 升级导致 Stream 或异步 API 的签名变了。比如旧版EventChannel.receiveBroadcastStream()的参数可能带arguments，新版则取消了，这类变动很容易被忽略。
我给的建议是：锁版本。在pubspec.yaml里把 Flutter SDK 约束写死，同时确认 OpenHarmony SDK 版本和引擎版本匹配，避免升级后出现一堆不明所以的编译报错。开发机上装多个 Flutter 版本的话，可以用 FVM 来管理不同项目的 Flutter SDK，项目间切换互不干扰，这个工具在 OpenHarmony Flutter 开发上也适用。
6. 最后再分享一点我在实际项目里的体会
StreamBuilder 这套东西，放到 OpenHarmony 上确实不是新概念，但恰恰因为平台新、设备杂，反而更考验你对数据流节奏的控制能力。我见过很多项目在 OpenHarmony 上跑 Flutter，功能都做出来了，但细节一调试就露馅，多数问题都出在数据流的频率、订阅生命周期的管理上，而不是 StreamBuilder 本身。
如果你现在正准备在 OpenHarmony 上做 Flutter 业务模块，我的建议是：一开始就按响应式数据流的思路来设计页面状态，不要先用setState跑通再回来重构。重构成本永远比一开始就用对方案要高。同时，把 Stream 相关的代码集中在独立的管理类里，不要在 Widget 里到处创建StreamController，否则后期维护会非常痛苦。
还有一个小细节：开发阶段多打开 DevTools 看性能面板，关注 rebuild 次数。StreamBuilder 用得好，页面大部分时间应该是“静”的，只有数据到达那一瞬间才 “动”。如果你发现页面在没有任何数据事件时也在频繁 rebuild，那八成是 Stream 管理或组件设计上有问题，早发现早解决，别等上线了再查。
