Go tcell Show 和 Sync 重绘有什么区别

Go tcell 的 Show() 用于把逻辑屏幕的修改显示出来；Sync() 则按“物理显示可能已失配”处理，重新更新全部可见单元格。日常内容变化优先 Show，用户主动要求重绘、显示受到其他输出干扰或窗口调整需要恢复时，再考虑 Sync。Sync 不是更高级的 Show，也不是业务模型的同步方法。

官方地址：https://github.com/gdamore/tcell

我在为这个最小交互示例安排刷新入口时，把“状态改变”和“恢复显示”拆成两条路径：按 n 改变计数并 Show，按 Ctrl+L 保持当前状态并 Sync。这个取舍来自接口语义，不是终端性能实测。下面固定使用 v2.8.1；官方仓库主分支目前是 v3，不把主分支 API 混进 v2 示例。

先看逻辑内容是不是已经正确

SetContent 修改逻辑单元格，并不立即显示。若程序只更新业务计数，没重新写入单元格，Show 和 Sync 都不会替你计算新文本。我习惯先把问题分成三层：业务状态、逻辑屏幕、物理显示。前两层错误，应该修复绘制函数；只有显示层失配时，强制重同步才对症。

“代码重画了所有格子”和“后端把所有格子再次发给终端”也不是同一件事。应用可以按当前模型重新构造逻辑画面，后端仍采用 Show 的优化输出策略。不要仅凭绘制函数遍历全屏，就断言终端正在全量刷新。

Show 和 Sync 的差别落在显示假设上

官方接口提醒 Sync 可能有额外开销和视觉干扰，不宜无条件放进每次循环。v2.8.1 的终端实现中，Show 与 Sync 都进入绘制函数；Sync 额外设置清屏标记并使单元格状态失效。这个实现细节解释了为何重复 Sync 不是免费的保险，但不代表所有平台都有完全相同的输出字节序列。

对我来说，这种区分的好处是故障定位更清楚：普通输入走正常刷新，用户觉得画面异常时有一个明确恢复快捷键。代价是应用还需要保留独立绘制逻辑，不能把 Sync 当成一键修复所有问题。

把普通刷新和恢复重绘写成独立分支

下面保存为 main.go。内容只用 ASCII，避免把宽字符占格问题混入这个对比；绘制函数限制在当前屏幕尺寸内，退出时释放 Screen 资源。

package main

import (
    "fmt"
    "os"

    "github.com/gdamore/tcell/v2"
)

func paint(s tcell.Screen, count int) {
    // 重新构造逻辑画面，Clear 本身不会直接显示。
    s.Clear()
    w, h := s.Size()
    if h = w {
            break
        }
        s.SetContent(x, 0, r, nil, tcell.StyleDefault)
    }
}

func run() error {
    s, err := tcell.NewScreen()
    if err != nil {
        return err
    }
    if err := s.Init(); err != nil {
        return err
    }
    // 所有正常返回路径都恢复终端并释放资源。
    defer s.Fini()
    count := 0
    paint(s, count)
    s.Show()

    for {
        ev := s.PollEvent()
        if ev == nil {
            return nil
        }
        switch e := ev.(type) {
        case *tcell.EventResize:
            // 尺寸改变后按当前模型重新绘制，再恢复显示。
            paint(s, count)
            s.Sync()
        case *tcell.EventKey:
            switch {
            case e.Key() == tcell.KeyEscape || e.Key() == tcell.KeyCtrlC:
                return nil
            case e.Key() == tcell.KeyRune && e.Rune() == 'q':
                return nil
            case e.Key() == tcell.KeyCtrlL:
                // 用户要求恢复画面；不改变业务计数。
                paint(s, count)
                s.Sync()
            case e.Key() == tcell.KeyRune && e.Rune() == 'n':
                // 普通业务变化只做正常显示提交。
                count++
                paint(s, count)
                s.Show()
            }
        }
    }
}

func main() {
    // run 返回时 Fini 已执行，再输出错误。
    if err := run(); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

# 在空示例目录初始化模块，固定本文使用的版本。
go mod init example.local/tcell-refresh
go get github.com/gdamore/tcell/v2@v2.8.1
# 在支持的交互终端里自行体验两个刷新入口。
go run .

这份示例未在本机执行，不提供截图或耗时数据。按代码可推导的预期是：n 增加 count，Ctrl+L 不增加 count，q、Escape、Ctrl+C 结束程序。若 Ctrl+L 后文字仍然是旧计数，应检查模型与 paint 的参数，而不是再循环调用 Sync。

哪些现象不能靠 Sync 掩盖

屏幕出现残留时，先问旧区域是否已经清理、布局是否用当前 Size、文字是否越界，再考虑物理显示被其他程序输出污染。在 tcell 管理画面期间直接 fmt.Println，会绕过逻辑单元格模型；更稳妥的设计是把日志写到独立目标，或把消息纳入应用画面。不要一边继续外部输出，一边期待每帧 Sync 永久解决冲突。

我会把 Sync 留作明确恢复动作，而不是每个按键后的默认。对常规列表、计数器和选择状态，这个分工容易维护；如果你的终端后端有特殊问题，仍需按具体平台定位，不能用本文断言所有闪烁或残影都来自刷新接口。

常见问题与快速判断

Clear 后还需要 Show 吗？需要显示提交。Clear 改的是逻辑画面，随后调用 Show 或 Sync 才显示。

Sync 后还要再 Show 一次吗？通常没必要为同一份画面紧接着重复提交；Sync 自己包含显示更新。后面有新内容修改，再正常刷新。

窗口变化只调用 Sync 就够吗？若应用布局依赖尺寸，应重新计算并重建逻辑内容。本例先 paint 再 Sync，不把布局责任交给刷新方法。

我的检查顺序是：状态值正确→逻辑单元格正确→提交入口正确→是否真的存在显示失配。日常用 Show，恢复用 Sync，布局和业务计算留在自己的绘制代码里。

参考：v2.8.1 Screen 接口、v2.8.1 终端实现、官方版本说明。