Go tcell 怎么在程序退出时恢复终端状态

我在写 tcell 终端程序时，最容易被忽略的不是画面刷新，而是退出后终端仍然像“被程序接管”：输入不回显、光标状态异常，甚至下一条命令看起来也不正常。这个问题的核心不是手动发送一组 ANSI 字符，而是让 tcell 的 Screen 生命周期完整闭合。

结论：在 s.Init() 成功后立刻注册一次延迟清理，用 s.Fini() 作为所有可控退出路径的共同出口；正常退出用 return，panic 则清理后重新抛出。不要用 os.Exit 代替返回，因为它会跳过 defer。

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

先把 Screen 的清理责任固定下来

tcell 的初始化分成两个有区别的动作：NewScreen 创建屏幕对象，Init 才把它切换到可工作的终端状态。只有第二步成功后，才适合把 Fini 绑定到当前函数的生命周期。这样初始化失败不会误走一段并未建立完成的清理逻辑，也能让后续所有 return 自动经过同一个出口。

package main

import (
	"log"

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

func run() error {
	// NewScreen 只创建抽象屏幕，Init 成功后才进入终端工作状态。
	s, err := tcell.NewScreen()
	if err != nil {
		return err
	}
	if err := s.Init(); err != nil {
		return err
	}
	// 所有可控 return 都会先执行 Fini，恢复终端并释放 tcell 资源。
	defer s.Fini()

	s.Clear()
	s.PutStr(0, 0, "按 Esc 退出")
	s.Show()
	return nil
}

func main() {
	// 入口保留错误日志，避免把初始化失败误认为终端未恢复。
	if err := run(); err != nil {
		log.Print(err)
	}
}

这里的关键顺序是“Init 成功，马上 defer Fini”。不要把 defer 放在很深的事件分支里，也不要在每个退出按键中分别写一份清理代码；分散的出口最容易漏掉异常分支。

正常退出和 Ctrl+C 都用 return 收口

tcell 官方教程通过 EventQ 接收事件，按键事件可以让主循环结束。退出分支只需要跳出当前函数，延迟的 Fini 会统一执行。对于 Ctrl+C，终端既可能产生键盘事件，也可能产生操作系统中断；工程里可以同时保留键盘分支和 signal.NotifyContext，但最终动作仍然应该是返回。

func runScreen() error {
	// 初始化成功后，退出责任由当前函数统一承担。
	s, err := tcell.NewScreen()
	if err != nil {
		return err
	}
	if err := s.Init(); err != nil {
		return err
	}
	defer s.Fini()

	for {
		// EventQ 在 Fini 后不应再写入；主循环只在当前屏幕有效时读取。
		ev := 

如果程序还要响应系统信号，可以把信号转成一个可控的退出条件，再让同一个函数返回。例如用 signal.NotifyContext 监听 os.Interrupt，在 select 中选择上下文结束或 tcell 事件。重点是不要在信号回调里直接 os.Exit，否则 defer 仍然来不及执行。

panic 时要恢复终端，也要保留 panic

只写 defer s.Fini() 已经能覆盖大多数 panic 场景，因为 defer 会在栈展开时运行。但如果清理动作和故障记录需要放在同一处，官方教程采用了“先 recover、清理、再 panic”的写法。这样做的目的不是吞掉异常，而是保证终端恢复后仍交给 Go 的 panic 机制输出堆栈。

func runWithPanicSafety() (err error) {
	// 只有 Init 成功后才注册 panic 清理，避免处理半初始化的屏幕。
	s, err := tcell.NewScreen()
	if err != nil {
		return err
	}
	if err = s.Init(); err != nil {
		return err
	}
	defer func() {
		// 先取出 panic 值，随后无论如何都恢复终端状态。
		panicValue := recover()
		s.Fini()
		// 重新抛出原 panic，保留调用栈和故障语义。
		if panicValue != nil {
			panic(panicValue)
		}
	}()

	// 业务事件循环或渲染逻辑发生 panic 时，仍会经过上面的清理函数。
	return nil
}

这个模式只适合当前函数拥有屏幕生命周期的场景。不要在多个层级同时对同一个 Screen 注册相互独立的 Fini；如果确实需要封装，就让最外层拥有清理权，内层只返回错误。

别让 os.Exit 和后台写入破坏清理边界

os.Exit 会直接结束进程，不执行 defer；被 SIGKILL 强制终止也没有机会运行用户态清理。因此，能由程序控制的退出都应改成返回错误、返回状态，或把退出请求发送给主循环。对不可控的强杀，只能接受终端可能来不及恢复，并依赖用户重新打开终端或执行 shell 的复位动作。

另一个容易漏掉的边界是后台 goroutine。tcell 的事件队列在 Fini 后不应继续写入；如果后台任务会投递事件，应先关闭任务或用取消信号让它停止，再让主函数返回。不要在清理函数里等待一个还会继续向 EventQ 写入的 goroutine，否则退出可能互相等待。

最后可以按这份清单收口：Init 成功后只绑定一次 Fini；退出按键和信号都转成 return；panic 清理后重新抛出；后台 goroutine 在 Fini 前停止写事件；不把 os.Exit 当成普通返回使用。

相关问题

tcell 的 Fini 和 Clear 是一回事吗？ 不是。Clear 只清除逻辑屏幕内容，Fini 才负责结束屏幕并释放资源、恢复终端环境。

只处理 Esc 还需要 panic 清理吗？ 需要。渲染、事件处理或业务代码都可能 panic，清理应该绑定生命周期，而不是只绑定某个按键。

为什么不能在 defer 里直接 os.Exit？ 因为那会让当前清理函数之后的其它 defer 无法继续执行，也会让退出语义变得难以组合。