Flutter流行为疑惑：调用setState却未重建Widget树

嘿，我来帮你理清这几个疑问，结合你的代码和Flutter的运行机制来拆解：

1. 为什么每次调用setState只触发两次Widget重建？ #

这是因为Flutter会对连续的setState调用进行批量合并处理。你的代码里，HTTP请求返回的是完整的JSON数组，经过expand转换后，所有Photo对象几乎是同步、快速地被发送到Stream中的。Flutter为了性能优化，不会每次setState都立刻触发重建，而是会把短时间内的多次setState合并，只在这一批更新结束后执行一次完整的Widget树重建。

你看到的输出顺序：

• 第一次BUILD!!!是PhotoList初始化完成后的首次构建；
• 随后的一堆ADD!是Stream快速推送所有Photo时，每次执行list.add(p)的打印；
• 最后一次BUILD!!!是Flutter合并所有setState请求后，触发的批量重建。

如果想验证批量处理的逻辑，你可以在map((map) => Photo.fromJsonMap(map))之后加一个延迟，比如：

.map((map) async {
  await Future.delayed(Duration(milliseconds: 100));
  return Photo.fromJsonMap(map);
})

这样每个Photo对象会间隔100ms被发送，你就能看到ADD!和BUILD!!!交替打印的效果了。

2. 若列表一次性填充完成后才重绘，使用Stream的意义何在？ #

这个示例其实是用了一个“一次性流”来演示用法，但Stream的真正价值在于处理异步、流式产生的数据：

• 比如服务器采用分块响应（比如分页加载的流式返回、Server-Sent Events），可以边接收数据边显示，不用等所有数据加载完成；
• 可以结合流操作符（比如where过滤、debounceTime防抖、switchMap切换流）做复杂的异步逻辑处理，比单纯的async/await更灵活；
• 支持订阅者的暂停、恢复、取消，适合处理需要动态控制的异步场景，比如用户下拉刷新时暂停流，刷新完成后恢复。

3. 若HTTP请求一次性返回所有数据，为何用Stream填充长列表而非直接async/await后填充？ #

虽然一次性数据用async/await也能实现，但Stream有这些优势：

• 渐进式显示：解析一个数据就显示一个，对于超大数组来说，用户不用等整个JSON解析完成就能看到内容，提升感知体验；
• 错误处理更灵活：可以在流的每个阶段捕获错误（比如解析某条数据失败时，不会导致整个列表加载失败）；
• 代码扩展性更强：如果后续需求变成分页加载或者流式返回，只需要修改流的数据源部分，不用大改UI逻辑；
• 这个示例本身就是为了演示Stream在Flutter中的结合用法，帮助理解流与状态更新的配合。

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