2026 年 11 月 3 日，跨平台 GPU 终端模拟器 kitty 正式发布 0.50.0 版本，带来两项重头更新，分别是脱离常规网格布局的停靠窗口（Docked windows），以及支持连同回滚历史一并保存的注销后恢复（Restore after logout）。表面上看，这只是一次常规的功能补齐；放在现代终端演进的脉络里，作者 Kovid Goyal 正试图在不引入后台守护进程的前提下，直接用终端原生 GUI 能力，把原本属于 tmux 等终端复用器和 Neovim 布局插件的活儿彻底接管过来。
这并不意味着你可以立刻卸载 tmux。kitty 0.50.0 的状态恢复本质上是一次克制的 UI 快照，而非后台进程保活；它在 macOS 与 Linux 之间还藏着单看更新日志极易忽略的安全机制与桌面环境落差。
为什么注销恢复替代不了 tmux 的进程保活
许多开发者看到 kitty 终于支持在系统注销、重启或关机时保存所有系统窗口、标签页、分屏与回滚缓冲区（scrollback），第一反应是困扰多年的终端重启丢上下文问题解决了。这项功能解决了早期遗留的 macOS 恢复需求（Issue #1197），但如果你指望它像 tmux 或内置 mux server 的 WezTerm 那样在重启后让正在运行的程序继续跑，就会踩空。
在配置中将默认值为 no 的 restore_session_after_logout 手动设为 yes 后，kitty 保存的会话状态在下次启动恢复时仅消耗一次。恢复时，它只重新拉起 Shell，并在新 Shell 上方打印带有保存时间标记的文本、格式和超链接回滚历史，绝不会重启除 Shell 以外任何正在运行的前台程序。
这不是技术上做不到，而是维护者主动踩了刹车。在 PR #10659 的开发讨论中，Kovid Goyal 曾短暂考虑过自动重启全屏应用程序，但在 2026 年 10 月 16 日砍掉了这一特性，理由是自动重启前台程序过于危险——没人希望电脑重启后，终端自动把关机前挂着的数据库删除脚本或未完成的部署命令再跑一遍。
拒绝后台守护进程，决定了 kitty 恢复的是工作现场，而不是运行态。
单看官方更新日志，读者很容易产生另一个误解，以为全平台都享受到了高规格加密与随时恢复。实际上，这里有两道隐形门槛：
- 触发条件严苛状态恢复仅针对操作系统层面的有序注销、重启或关机（orderly logout, restart, or shutdown）。如果你平时习惯随手按快捷键执行普通退出应用（ordinary app quit），或者遭遇程序崩溃、断电，官方文档并未承诺触发恢复。
- 跨平台安全落差在 macOS 上，每个保存的实例确实会使用存储在登录钥匙串中的独立随机密钥加密，且恢复后立即销毁密钥；但在 Linux 上，保存的状态完全未加密，仅靠用户文件权限存放在缓存目录中，且硬性要求桌面环境支持 Inhibit desktop portal 的第 3 版（version 3）。
- 风险.Linux 开发者若经常在终端直接打印明文密钥、生产环境日志或敏感配置，开启
restore_session_after_logout会把整段回滚历史以明文落盘到用户缓存目录，存在本地数据泄露隐患。
横向对比同赛道的现代终端，各家在持久化上的取舍泾渭分明。WezTerm 选择内置 mux server 保持后台进程存活，或配合 resurrect.wezterm 插件恢复；大热的 Ghostty 目前仅在 macOS 上支持窗口、标签与分屏布局恢复（window-save-state 在 Linux 上无效），且回滚历史仅驻留内存。kitty 0.50.0 补上了跨平台回滚历史落盘的拼图，但把长连接保活的职责依然留给了服务端复用器。
停靠窗口补齐终端即 IDE 的最后一块布局拼图
如果说状态恢复是防守型更新，那么停靠窗口（Docked windows）就是 kitty 向传统 IDE 发起的正面进攻。
长期以来，想把 Neovim 或 Helix 等终端编辑器折腾成完整 IDE 的开发者，都卡在布局算法的两难里。如果用终端原生的分屏（Splits），所有窗口都受制于网格或平铺布局流，一旦在编辑器旁开一个文件树或底部开一个 Shell，分屏重排时侧边栏就会跟着变形；如果在编辑器内部用插件模拟侧边栏和内置终端，又会损失外层终端的高性能渲染，或者在套上 tmux 后遭遇快捷键冲突、剪贴板穿透繁琐、双层回滚历史割裂以及原生图形协议失效的痛点。
kitty 0.50.0 给出的解法是直接通过 launch --type=window-dock 或 launch --type=tab-dock，把窗口吸附在另一个窗口或整个标签页的边缘。这些停靠窗口独立于常规布局之外，不会参与平铺重排，天生适合用来挂载状态栏、文件树或伴随编辑器的 Shell。更巧妙的是，窗口级停靠（window-dock）与宿主窗口绑定了生命周期——它会跟着主窗口一起跨标签页移动，当你在编辑器里退出关闭主窗口时，挂载在旁边的伴随窗口也会自动一同关闭，且整套停靠关系可以直接保存在会话（Sessions）文件中。
配合 0.50.0 同步引入的将标签页作为命名工作区（launch --focus-existing）、程序状态汇报协议（OSC 7501，可在标签栏显示程序正在运行、完成、失败或等待用户输入），以及 0.43 至 0.48 版本陆续铺垫的原生多光标协议、带语法高亮与图像预览的快速文件选择器、跨 SSH 拖拽文件和垂直标签页，kitty 已经把轻量级桌面工作区的骨架搭完了。
压榨 AVX-512 性能背后，本地与远程工作流该如何选型
把这么多桌面级特性塞进终端，会不会把 kitty 变成第二个臃肿的 Electron？就在一个多月前的 2026 年 9 月 21 日，kitty 刚刚通过 0.49 版本交出了一份底层性能答卷。
需要提醒的是，官方更新日志把 0.49 的多项细分加速比例（如 +35%、+50%、+75%）与 0.50 并列展示在近期特性里，容易让人误以为这是 0.50 的新增提速或可以简单线性相加。实际上，这一轮优化是在 0.49 版本完成的，真实工作负载下的综合有效吞吐量提升为 15-35%。
为了榨干硬件性能，kitty 在 0.49 中重写了多条热路径，不仅在回滚缓冲区远大于 CPU 缓存时通过内存预取提速约 35%，还在 Intel Ice Lake+ 与 AMD Zen 4+ 处理器上自动启用基于 AVX-512 的解码器，将多字节文本解码再推高约 75%，并用 SIMD 向量化将图形协议图像与动画帧的 Alpha 混合速度提升了 2 到 3.5 倍。不过，kitty 官方性能页面（performance）公布的横向对比表目前仍停留在测试 kitty 0.33 版本，且其自带的 kitten __benchmark__ 工具默认抑制屏幕渲染以侧重测试解析器速度，读者在参考官方跑分表时需留意这一基线滞后。
看清了这些技术底牌，不同处境的开发者在面对 kitty 0.50.0 时就不难做出切换决策：
- 建议.如果你是以本地开发为主的 Neovim 或 Helix 用户，可以直接利用
window-dock和 0.45 引入的快速文件选择器，把文件树、状态栏和伴随 Shell 剥离到编辑器外部由 kitty 原生托管，彻底告别 tmux 带来的图形协议降级与快捷键冲突；但如果你是重度依赖 SSH 远程开发、需要在断网或重启后保持编译任务和长连接存活的运维与后端工程师，kitty 的注销恢复帮不了你，老老实实留在 tmux 或 WezTerm 的 mux server 里才是稳妥选择。
接下来最值得盯住的两个变量，一是社区会围绕 window-dock 造出多少开箱即用的状态栏与文件树 Kitten 工具；二是 Kovid Goyal 后续是否会在 Linux 端接入 Secret Service API，补上回滚缓存明文落盘那块安全短板。