Go Bubble Tea 定时消息为什么触发一次就停止

我第一次给 Bubble Tea 界面加定时刷新时，画面只更新了一次，直觉上会怀疑定时器失效。真正原因通常不是 goroutine 没启动，而是把 tea.Tick 当成了自动循环的 ticker。它返回的 Cmd 只负责产生一条 TickMsg；要持续触发，必须在 Update 收到消息后重新返回下一次命令。

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

定时消息只触发一次是 Bubble Tea 的预期行为。持续刷新应由 Update 明确重新调度，退出时则返回 nil，不要把循环责任藏在一次 tea.Tick 调用里。

• 原因：tea.Tick 是一次性命令，不是长期运行的时间源。
• 做法：在 Update 处理 TickMsg 后返回新的 tickCmd()。
• 边界：退出或暂停状态不要继续返回命令，间隔应按刷新成本选择。

一次性 Tick 与持续定时的边界

Bubble Tea 的命令是“产生一条消息的工作描述”。调用 tea.Tick 时，计时从这次命令启动；时间到达后，回调把时间包装成消息并交给 Update。这次命令完成后不会自己复制下一份命令，所以只在 Init 中返回一次时，界面自然也只收到一次 tick。

可以把它和 time.Ticker 区分开：后者代表持续产生时间事件的对象，而 tea.Tick 更像一次延迟消息工厂。这个边界正是“第一次正常、后面不动”的根因。

让 Update 负责重新安排下一次 Tick

持续定时的关键不是启动更多 goroutine，而是让消息处理和状态更新保持在同一个模型循环里。下面的片段把重新调度集中在 Update，便于在退出、暂停或请求失败时决定是否继续。

type tickMsg time.Time

func tickCmd() tea.Cmd {
	return tea.Tick(time.Second, func(t time.Time) tea.Msg {
		// 每次调用只创建一条待发送的 Tick 消息。
		return tickMsg(t)
	})
}

func (m model) Init() tea.Cmd {
	// 首次进入模型时安排第一条消息。
	return tickCmd()
}

func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
	switch msg := msg.(type) {
	case tickMsg:
		if m.quitting {
			// 退出状态不再安排新命令，避免无意义的刷新。
			return m, nil
		}
		m.lastTick = time.Time(msg)
		// 持续性来自这里返回下一次命令，而不是 Tick 自动循环。
		return m, tickCmd()
	}
	return m, nil
}

这里的 tickMsg 只是示例消息类型，实际项目也可以携带刷新原因、请求编号或错误信息。重要的是每次收到它后都要明确决定下一步：继续返回 tickCmd()，还是因为退出、暂停或失败策略返回 nil。

反例、间隔和退出边界怎么判断

最常见的反例是在 Update 中只更新字段却返回 m, nil，这样状态虽然改了，下一次 Tick 却没有被安排。另一个反例是在每次按键或每次刷新都无条件创建命令，可能让多个延迟消息同时在路上，表现成重复刷新。

间隔不要只按“越短越灵敏”来定。刷新内容包含网络请求、文件扫描或复杂渲染时，应把请求取消、结果过期和退出状态一起考虑；只需要显示相对时间时，较长间隔通常更容易控制。若确实需要独立的持续时间源，再评估 time.Ticker 与消息桥接，但不要在一个模型里同时维护两套重复时钟。

相关问题

为什么 Init 里返回 tea.Tick 仍然只触发一次？

因为 Init 只启动了一条命令。它完成后不会自动把同一个命令重新放回队列，需要在 Update 的 tick 分支返回新的命令。

Update 修改了时间字段但界面没动，应该先查什么？

先查返回值是否仍是 m, tickCmd()，再查 View 是否读取了该字段；只修改模型而不重新调度，只会得到一次可见变化。

退出时为什么建议返回 nil？

退出状态已经不需要新的定时消息。返回 nil 能把停止条件写在消息处理边界上，避免继续产生没有消费者的刷新工作。