Go tview 怎么把后台数据变更提交到界面线程

Go tview 中，后台 goroutine 不要直接调用 SetText、SetCell 或修改其他 primitive。更稳妥的做法是让后台任务只负责查询和整理数据，再把真正的界面变更提交给 Application.QueueUpdate 或 QueueUpdateDraw。前者保证变更在应用事件循环中串行执行，后者还会在闭包执行后立即刷新画面。

官方地址：https://github.com/rivo/tview

判断标准很简单：后台线程负责“准备什么”，tview 的界面线程负责“怎么改控件”。需要改完马上看到结果就用 QueueUpdateDraw，只需要安全提交、允许后续统一绘制就用 QueueUpdate。

把后台任务和界面提交拆成两层

tview 的 primitive 通常可以被多个 goroutine 触达，但控件的复合操作并不会因为某个 setter 存在就自动变成线程安全。比如后台任务一边刷新表格单元格，主循环一边读取表格进行绘制，就可能产生数据竞争。解决方案不是给每个字段外面再套一把业务锁，而是把 primitive 的修改统一交给 Application 的更新队列。

下面的示例让 goroutine 只生成结果，界面提交则集中在一个闭包里。闭包内的多次修改会按同一批次执行，读者不需要在业务代码中自行模拟“界面线程”。

package main

import (
    "fmt"
    "time"

    "github.com/rivo/tview"
)

func main() {
    app := tview.NewApplication()
    view := tview.NewTextView().SetBorder(true).SetTitle("任务状态")

    go func() {
        // 后台只做耗时工作，不直接碰 tview primitive。
        time.Sleep(300 * time.Millisecond)
        result := "查询完成：42 条记录"

        app.QueueUpdateDraw(func() {
            // 这段闭包在 tview 的事件循环中执行，可安全更新控件。
            fmt.Fprintln(view, result)
        })
    }()

    if err := app.SetRoot(view, true).Run(); err != nil {
        panic(err) // 启动失败时保留错误，便于定位终端环境问题。
    }
}

QueueUpdate 和 QueueUpdateDraw 的选择边界

QueueUpdate 会等待传入的函数执行完，但不会自动触发绘制；适合连续提交多次状态、最后由下一轮事件或一次显式 Draw 统一刷新。QueueUpdateDraw 在执行函数后立即绘制，适合“后台任务完成后马上显示状态”这一类单次结果。

两者都不是“任意位置都能调用”的刷新按钮。tview 官方并发说明特别提醒：如果代码本来就在键盘或鼠标事件处理器中，主循环已经在处理这次事件，此时直接修改 primitive 即可；在处理器里再调用 QueueUpdate 或 QueueUpdateDraw，可能因为等待当前事件循环再次取队列而形成死锁。

把一组状态变更放进同一个闭包

后台数据往往不只更新一处。比如列表内容、计数文本和错误提示需要同时变化，最好先在后台构造不可变的结果，再用一次排队提交完成清理、写入和状态切换。这样绘制看到的是一组完整状态，不会先显示新计数、后显示旧列表。

type snapshot struct {
    rows   []string
    status string
}

func applySnapshot(app *tview.Application, list *tview.List, status *tview.TextView, s snapshot) {
    app.QueueUpdateDraw(func() {
        // 清理和写入在同一批提交中，避免界面短暂处于半更新状态。
        list.Clear()
        for _, row := range s.rows {
            list.AddItem(row, "", 0, nil)
        }
        status.SetText(s.status)
    })
}

这里的 snapshot 也划定了数据边界：后台不把数据库游标、可变共享 slice 或正在写入的对象直接交给界面层。若后台还会继续修改 rows，应在提交前复制出当前快照；否则队列虽然串行，数据本身仍可能被另一处并发修改。

用判断清单避免“看起来刷新了”

第一，确认调用点是否位于 goroutine；如果是，就不要直接改 primitive。第二，确认是否要求提交后立刻显示；要求立即显示就选 QueueUpdateDraw，否则可用 QueueUpdate 合并刷新。第三，确认是否已经在 tview 事件处理器中；若是，直接修改并让主循环完成绘制。第四，确认停止应用时后台任务不会继续向已经结束的 Application 投递更新，必要时用取消信号让后台 goroutine 收尾。

最后不要把 Draw 当成并发保护。它只负责安排或执行绘制，不能替代把 primitive 修改放入应用更新队列。把“数据准备”“界面提交”“是否重绘”分开，tview 的并发行为就更容易推断。

相关问题

QueueUpdate 和 QueueUpdateDraw 的核心区别是什么？

两者都会把函数交给 tview 事件循环串行执行；区别是 QueueUpdateDraw 会在函数执行后立即刷新画面，而 QueueUpdate 不会自动绘制。

后台 goroutine 只调用 Draw 可以吗？

如果没有任何 primitive 修改，只是需要刷新已经安全更新的数据，可以调用 Draw。但只调用 Draw 不能保护同时发生的控件写操作，控件变更仍应放入更新队列。

参考资料：https://github.com/rivo/tview/wiki/Concurrency；https://raw.githubusercontent.com/rivo/tview/master/application.go