Go Bubble Tea Batch 与顺序执行命令有什么区别

在 Bubble Tea 中，tea.Batch 和 tea.Sequence 都是把多个 tea.Cmd 组合成一个命令，但选择依据完全不同：前者适合互不依赖的任务并发执行，后者适合必须按声明顺序执行的任务。最容易忽略的一点是，Sequence 只保证命令执行顺序，并不会把前一个命令的结果自动传给后一个命令。

官方地址：https://github.com/charmbracelet/bubbletea

如果多个查询可以独立开始，用 Batch；如果第二个命令必须等第一个命令完成，或者外部资源不允许并行访问，用 Sequence。两者产生的消息仍然要回到 Update，再由模型决定界面状态。

先看 Batch 与 Sequence 的能力边界

Bubble Tea 官方实现对两者的定义很直接：Batch 会并发执行一组命令，结果没有顺序保证；Sequence 会一次执行一个命令，并按照传入顺序处理。传入的 nil 命令会被忽略，只有一个非空命令时还会直接返回该命令。

什么时候应该使用 tea.Batch

只要命令之间没有输入依赖，就可以把它们交给 Batch。例如页面启动时同时读取用户偏好和未读数量，它们都只依赖已有的会话信息，彼此不需要等待。

type prefsMsg struct {
    // 保存偏好查询的结果，供 Update 更新模型。
    theme string
}

type unreadMsg struct {
    // 保存未读数量，避免把统计值混入偏好消息。
    count int
}

func loadPrefs() tea.Cmd {
    return func() tea.Msg {
        // 这里模拟独立的偏好读取；真实项目中可替换为文件或接口调用。
        return prefsMsg{theme: "dark"}
    }
}

func loadUnread() tea.Cmd {
    return func() tea.Msg {
        // 这里模拟独立的统计查询；不要依赖 loadPrefs 的返回消息。
        return unreadMsg{count: 3}
    }
}

func (m model) Init() tea.Cmd {
    // 两个命令没有先后依赖，Batch 允许运行时并发执行。
    return tea.Batch(loadPrefs(), loadUnread())
}

在 Update 中分别匹配 prefsMsg 和 unreadMsg 即可。消息到达顺序可能不同，因此不要用“收到第一条就是偏好、第二条就是未读”这样的写法，而应根据消息类型更新对应字段。若两个命令都修改同一个共享资源，还需要在命令内部处理并发安全，Batch 不会替你合并业务冲突。

什么时候应该使用 tea.Sequence

当任务本身要求固定顺序时，Sequence 能表达“先执行 A，再执行 B”。例如先刷新本地缓存，再读取依赖该缓存的文件；或者先发送一个准备命令，再发送后续清理命令。

func prepareCache() tea.Cmd {
    return func() tea.Msg {
        // 先完成准备动作，返回消息只用于记录状态或错误。
        return cachePreparedMsg{}
    }
}

func refreshView() tea.Cmd {
    return func() tea.Msg {
        // 该命令排在准备动作之后，但不会自动读取 cachePreparedMsg。
        return viewRefreshedMsg{}
    }
}

func (m model) refreshCmd() tea.Cmd {
    // Sequence 保证两个 Cmd 按声明顺序执行，不保证它们之间自动更新 model。
    return tea.Sequence(prepareCache(), refreshView())
}

这里的“顺序”是命令执行层面的顺序，不是完整的业务事务。Bubble Tea 会把每个命令产生的消息送回程序，但 refreshView 的闭包在创建时就已经确定；它不会因为前一个消息刚刚产生，就自动拿到更新后的模型。

真正有数据依赖时，不要误用 Sequence

如果第二步必须使用第一步返回的令牌、文件 ID 或服务端版本号，通常应让第一条命令完成后回到 Update，再根据消息中的数据创建第二条命令。这样模型更新和下一次命令创建都发生在可见的消息处理边界内。

type tokenMsg struct {
    // 把后续请求真正需要的令牌带回 Update。
    token string
}

func fetchToken() tea.Cmd {
    return func() tea.Msg {
        // 真实项目中应在这里处理网络错误，并返回对应的错误消息类型。
        return tokenMsg{token: "session-token"}
    }
}

func fetchData(token string) tea.Cmd {
    return func() tea.Msg {
        // token 由 Update 传入，数据命令不会猜测前一步的结果。
        return dataMsg{value: "loaded with " + token}
    }
}

func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    switch msg := msg.(type) {
    case tokenMsg:
        // 只有拿到真实令牌后，才创建依赖它的下一条 Cmd。
        m.token = msg.token
        return m, fetchData(msg.token)
    case dataMsg:
        // 数据消息到达后再更新界面状态。
        m.value = msg.value
    }
    return m, nil
}

如果只是想让几个没有依赖的命令按某个固定顺序发出，Sequence 足够；如果下一步必须读取上一步的结果，回到 Update 再创建命令更清楚，也更容易处理失败、重试和取消。

nil、错误与选择清单

两种组合都会跳过 nil 命令，但它们不会自动替你聚合业务错误。建议为不同任务定义明确的消息类型，在 Update 中逐个更新状态；并发场景下还要考虑多个错误同时到达的展示策略，顺序场景下则要决定前一步失败后是否仍允许后一步继续。

• 任务互不依赖、结果到达顺序无所谓：选择 tea.Batch。
• 命令必须按固定顺序启动或执行：选择 tea.Sequence。
• 后一个命令需要前一个命令的返回值：在 Update 中收到消息后再创建后续 Cmd。
• 多个命令会写入同一资源：先设计并发安全和错误合并，不要把责任交给组合函数。

常见问题

Batch 返回的消息会按传入顺序到达吗？

不会。官方实现明确说明 Batch 没有结果顺序保证，Update 应按消息类型或任务标识处理，而不是依赖数组位置。

Sequence 能代替“第一步成功后再执行第二步”吗？

它能保证命令按顺序执行，但不负责把第一条消息转换成第二条命令的输入。需要使用第一步结果时，应在 Update 中判断成功后创建下一条 Cmd。

只有一条命令时还要调用 Batch 或 Sequence 吗？

可以调用，但 Bubble Tea 会忽略 nil，并在只有一个非空命令时直接返回它。为了表达意图，单条命令通常直接返回更清楚。