张瑞15129378030先说实话，这个问题我蹲过不止一次。用 PuTTY 连上远程服务器，进 byobu 想开个新窗格，习惯性按 F2，结果光标原地闪，终端里连个提示都没有。那一刻你可能会怀疑自己是不是记错快捷键了，或者 byobu 出了问题，但排查到最后你会发现，问题多半出在 PuTTY 的键盘协议和 tmux 的按键解析上。
这篇文章我会直接围绕“PuTTY 里 byobu 的 F2 按了没反应”这条主线，讲清楚它为什么失效、怎么绕过失效、以及怎么从根上把 F2 以及整排 F 功能键都修好。内容都是我实际在 Windows 上通过 PuTTY 连 Linux 服务器操作时验证过的，不绕弯子。
1. 先搞清楚 F2 在 byobu 里的职责，以及它消失时发生了什么
byobu 是 tmux（或 screen）的前端增强层，但绝大多数情况下你用的后端是 tmux。F2 在 byobu 的默认 tmux 配置里扮演的是“水平分割窗格并创建一个新 shell”的角色——也就是把当前终端横向切一刀，上下各开一个会话。按下 F2 之后，你会看到新窗格出现，并且旧窗格的提示符也会跟着重排，这是 byobu+tmux 最常见的用法之一。
那问题来了：你在 PuTTY 里按 F2，为什么没有任何反应？
先说一个常见的误解。很多人以为是 byobu 的快捷键没加载，或者 tmux 配置被改坏了，然后花很久去看 /etc/byobu 和 ~/.byobu 的配置。但实际上，大部分情况下配置毫发无损，问题出在按键从你的键盘到 PuTTY 再到远程终端这一整条链路上。
PuTTY 默认在“Keyboard”设置里选择的是 ESC[n~ 这类控制序列，但 F 功能键的处理并不总是走默认配置。F1 到 F4 在 PuTTY 里有专门的映射，在传统终端定义里，F1 发送的是 ESC O P，F2 发送的是 ESC O Q，F3 发送的是 ESC O R，F4 发送的是 ESC O S。而 tmux 需要正确识别 ESC O Q 才能触发分割窗格，一旦 PuTTY 发送的内容不是 tmux 预期的序列，或者 PuTTY 本身改动过键盘映射，那 F2 就变成了一串“不知名的转义序列”，终端程序只能忽略它。
我遇到的真实表现是：在 PuTTY 里按 F2，命令行直接没动静，甚至在某些情况下会插入一个字符或清掉当前行输入。这种混乱的反馈通常说明 PuTTY 和 tmux 之间对按键序列的理解出现了错位。
还有一个隐藏因素：byobu 本身会读取终端类型（TERM）来判断该发什么控制序列。你用 PuTTY 连接时，默认的 TERM 是 xterm，但 PuTTY 模拟的终端能力和真正的 xterm 有细微差异。byobu/tmux 依赖 TERM 来决定如何处理功能键，如果你在远程会话里把 TERM 改成了 screen 或 tmux，那 F 键的处理方式又会不一样。
简单总结一句：这不是 byobu 程序的 bug，而是 PuTTY 发送的按键序列和 tmux 期望的按键序列对不上，或者 PuTTY 的键盘模式不适合跑 byobu 这类全屏 TUI 程序。
从实际操作角度来看，我最推荐的处理顺序是这样：
- 先不急着改 PuTTY 配置，先验证 F2 到底有没有被远程 shell 收到，以及收到的是什么序列。
- 切换 PuTTY 键盘协议，看是否能恢复 byobu 的全部 F 功能键。
- 调整 byobu 的快捷键绑定，绕开 F2 这一键，改成不容易踩冲突的组合键。
第 1 步看起来多此一举，但能帮你确认问题层级，避免盲目改配置后把情况弄得更乱。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 逐步定位：用最小化手段验证 F2 是否真的“没有到达”远程 shell
在按 F2 没反应的当下，你会下意识去 byobu 里面找问题。但更好的习惯是先从外部验证按键事件的原始状态。下面这套排查方法不需要装额外软件，直接用 shell 自带能力就能完成。
2.1 在外面按 F2，看 shell 是否显示 ^[OQ
打开一个新的 PuTTY 窗口，先别进 byobu，直接在普通 bash 提示符下按下 F2，然后回车。你可能会看到下面两种结果之一：
- 如果终端直接显示了
^[OQ，说明 PuTTY 把 F2 映射成了标准的ESC O Q控制序列，这一般是健康状态。 - 如果终端显示了别的字符，比如
^[[12~或^[Oq，那就说明 PuTTY 的功能键定义偏离了常规，tmux 不一定认识。
我在自己 Windows 10 上的 PuTTY 0.78 里实测，默认配置下按 F2，bash 里显示的是 ^[OQ。也就是说，PuTTY 这一侧其实没什么大问题。那问题就可能出在 byobu 启动后对终端类型的变更，或者 byobu 里的 tmux 配置把 F2 重新绑定成“什么都不做”。
不过这里要提醒一点：PuTTY 的键盘配置在不同版本里默认值略有差异。老版本 PuTTY 的默认可能偏向 VT100+，新版本偏向 xterm。如果你用的是修改版 PuTTY，比如某些绿色汉化版，那键盘处理可能会被替换掉，这也是很多人忽略的坑。
2.2 用 cat 命令捕获原始按键字节流
这只是辅助手段，但能让你看到比 ^[OQ 更精确的内容。执行：
bash复制cat -v
然后按一下 F2，再按 Ctrl+C 退出。屏幕上会出现类似 ^[OQ 的字符。^[ 代表 ESC，OQ 是后面跟着的字母。如果输出是 ^[[Q，那 F2 用的就是另一种 CSI 序列。
tmux 对 F2 的标准定义有两种来源，一种是读取 terminfo 里的 kf2 能力，另一种是内置的默认键表。绝大多数情况下，tmux 认的是 ESC O Q 和 ESC [ 1 2 ~ 这类序列。如果你的 PuTTY 输出的是完全不同的组合，tmux 就没法把它识别成 F2。
2.3 在 byobu 内部按 prefix + ? 查看键位绑定
byobu 的默认 prefix 是 Ctrl+A（如果后端是 tmux，它沿用的更像 screen 的习惯）。在 byobu 里按 Ctrl+A 然后按 ?，能调出 key bindings 列表。搜索 F2，你会看到类似这样的定义：
text复制bind-key -n F2 new-window
或者是：
text复制bind -n F2 display-panes
不同版本 byobu 对 F2 的定义不完全一样。我遇到过某些发行版自带的 byobu 把 F2 绑成了 new-window（新建窗口），而不是 split-window -h（水平分割窗格）。这时候你以为“F2 没反应”可能只是表象，实际是它开了新窗口但你没注意窗口列表变了。
所以定位时一定要看两步：第一步看按键序列是否到达，第二步看 byobu 里 F2 到底绑定成了什么。如果绑定本身就不是分割窗格，那就算按键正常，行为也和你预期不符。
2.4 区分“PuTTY 吞键”和“byobu 不响应”
“吞键”是指 PuTTY 或者终端模拟层收到按键后没有把控制序列传给远程，而是自行处理了。对 PuTTY 来说，F2 并没有特殊系统功能，一般不会被 Windows 拦截，但如果你开了 PuTTY 的某些会话功能，比如 Window->Behaviour 里的 Full screen on Alt+Enter，可能会影响一部分按键。实测中 F2 没有被 PuTTY 界面层消费掉。
“byobu 不响应”则更常见，原因是 byobu 启动时设置了一个 TERM=screen.linux 或 TERM=tmux-256color，终端类型变化导致功能键的 terminfo 映射和 PuTTY 实际发送的序列不匹配。这一问题在 tmux 2.x 和 tmux 3.x 里都有，只是表现方式略有差别。
为了快速区分，你可以在 byobu 里按 Ctrl+A，然后输入 :set -g terminal-overrides "xterm*:kf2=\eOQ" 试试。如果 F2 立刻恢复了，那基本可以确定是 terminfo 映射问题。这条命令只对当前会话有效，不会写死配置，适合测试。
3. 解锁 F2：PuTTY 的键盘协议设置与 tweak 细节
PuTTY 里和功能键直接相关的是 Terminal -> Keyboard 这个页面，其中 The function keys and keypad 下拉框有多个选项，很多人一辈子都没点开过。这里我把几个常用选项列出来，并说明它们对 byobu 的影响。
3.1 PuTTY 功能键模式对比
| 模式 | F2 实际发送的序列 | byobu/tmux 识别情况 | 备注 |
|---|---|---|---|
| ESC[n~ | ESC[12~ |
部分 tmux 版本可以识别 | 兼容性一般 |
| Xterm R6 | ESC[12~ |
同上 | 与 Xterm 一致 |
| VT100+ | ESCOQ |
绝大多数 tmux 正常识别 | 推荐 |
| Linux | ESC[[B |
一般不识别 | 不适合 |
| SCO | ESC[G |
不识别 | 特殊环境用 |
| Application | 依赖 keypad 状态 | 会出问题 | 慎用 |
你可能会注意到，ESC[n~ 和 Xterm R6 在 F2 上发的序列几乎一样，都是 ESC[12~。这种序列不是 F2 的“第一标准”，但 tmux 的默认配置里通常也把 kf2 定为 ESC[12~，所以反而也能用。问题往往出在 you 的 PuTTY 被设置成了 Linux 或 SCO，这两种模式发的序列完全不是 tmux 认识的。
我的建议是直接选 Xterm R6。理由有两个：第一，它更接近现代终端的行为，tmux 和 byobu 对 xterm 系的 terminfo 支持最完善；第二，在 PuTTY 0.76 之后的版本里，Xterm R6 模式对 F1~F4 的映射更符合 tmux 的期待。
3.2 修改 PuTTY 设置并保存到会话
操作步骤很简单：
- 打开 PuTTY。
- 在左侧目录树里找到
Terminal -> Keyboard。 - 找到
The function keys and keypad，把值从默认改成Xterm R6。 - 回到
Session，在Saved Sessions里选中你要用的连接配置，点击Save。
如果你懒得改全局，只想在已打开的会话里临时生效，那只能先断开连接，改好设置再重连。PuTTY 没有提供“热修改键盘模式”的功能。
3.3 附加一个容易忽略的选项：Disable application keypad mode
在 Terminal -> Features 里有一个 Disable application keypad mode 的复选框。某些情况下，PuTTY 会和远程程序（比如 tmux、vim、htop）协商 keypad 状态，导致小键盘和功能键行为异常。如果你发现 F2 没反应的同时，数字小键盘也输入异常，可以把这一项勾上，强制关机到普通模式。
但注意，这个选项只影响 keypad，不直接影响 F2。不过我在排查时发现，很多由 PuTTY 引起的功能键错乱，往往伴随 keypad 模式漂移。勾选后虽然不能直接修复 F2，但能避免更多连带问题。
3.4 当你用的是 Windows Terminal 或其他终端时，PuTTY 设置就不再适用
这道题限定在 PuTTY，那就按 PuTTY 的逻辑来。但如果你在 Windows 上换用了 Windows Terminal 或 MobaXterm，F2 的处理路径完全不同，别再照搬 PuTTY 的选项。Windows Terminal 的 F2 默认直接发送标准 ANSI 序列，反而很少遇到这类问题。
4. 治标更治本：在 byobu/tmux 里把 F2 拽回正轨
有些场景下你没办法改 PuTTY，比如在公司电脑上 PuTTY 是锁死的、或者你远程连的是嵌在网页里的串口终端。这时候更靠谱的办法是从 byobu/tmux 侧做适配。
4.1 用终端重写（terminal-overrides）修复 F2
tmux 提供了 terminal-overrides 选项，允许你忽略 terminfo 里对某些键的定义，强制指定成你想要的序列。在 byobu 环境下，由于配置被封装了一层，最直接的方法是在 ~/.tmux.conf 里显式添加：
tmux复制set -g terminal-overrides "xterm*:kf2=\eOQ:kf3=\eOR:kf4=\eOS"
这里 \e 代表 ESC，OQ 是 F2 的标准尾部。加完之后执行：
bash复制tmux source-file ~/.tmux.conf
如果你用的是 byobu 的 tmux 后端，tmux 会在启动时自动加载 ~/.tmux.conf。不过 byobu 自己也有一个配置入口，它不是直接读 ~/.tmux.conf，而是通过 /usr/share/byobu/profiles/tmux 来包装。如果你发现改 ~/.tmux.conf 不生效，可能是 byobu 的 profile 优先级更高。
更保险的办法是在 byobu 内部执行：
bash复制byobu-tmux set -g terminal-overrides "xterm*:kf2=\eOQ"
并观察是否立即生效。如果生效，再考虑写进配置文件。
4.2 直接在 byobu 层重新绑定 F2
如果终端序列怎么调都别扭，那就把 F2 绑定成你想要的命令。byobu 的命令绑定方式有两种：一种是通过 ~/.byobu/keybindings.tmux，另一种是 through byobu-keybindings 命令行工具。
我比较推荐直接编辑 keybindings.tmux，因为它一目了然。先看看现有绑定：
bash复制byobu-tmux list-keys | grep F2
再往 ~/.byobu/keybindings.tmux 里添加：
tmux复制bind-key -n F2 split-window -h
这里是 -n 代表不需要前缀键，直接按 F2 就触发。split-window -h 是水平分割。如果你想上下分割，用 split-window -v。注意 byobu 的 tmux 后端里，-h 和 -v 的语义容易搞混，-h 是把窗口水平切一刀，容器左右排；-v 是垂直切一刀，容器上下排。别再记反了。
改完配置文件后，不一定每个版本 byobu 都会热加载。你可以退出 byobu 再重新进，或者临时执行：
bash复制byobu-tmux source-file ~/.byobu/keybindings.tmux
4.3 绑定成备用键：用 Ctrl+B 风格规避冲突
如果你不只是 F2 有问题，而是整个 F 区都乱，那我建议就别死磕 F 键了。tmux 传统是 Ctrl+B 作为 prefix，byobu 为了向 screen 用户靠拢改成了 Ctrl+A。在 byobu 里，你可以用 Ctrl+A 之后按 % 来水平分割，按 " 来垂直分割，这两个键不依赖 F 区，基本不会受终端功能键序列影响。
这是我实际最常用的兜底方案。不管 PuTTY 键盘模式怎么换，Ctrl+A 都是普通 ASCII 控制键，tmux 解析非常稳定。
4.4 给 byobu 的 tmux 后端设置正确的 TERM
有些情况下，PuTTY 的 F2 发的是标准序列，但 byobu 启动后设置的 TERM=screen.linux 会让 tmux 进入“Linux 控制台”模式，这个模式的 F2 定义变得很怪。我在 Debian 系服务器上遇到过，TERM=screen.linux 时 F2 在 tmux 里完全不响应；改成 TERM=tmux-256color 或 TERM=screen-256color 后，F2 立刻恢复。
要修改 byobu 启动时的 TERM，可以在 ~/.byobu/.tmux.conf 或 ~/.tmux.conf 里加：
tmux复制set -g default-terminal "tmux-256color"
set -ga terminal-overrides ",xterm*:Tc"
修改后需要退出所有 byobu 会话再重进，因为 default-terminal 只影响之后新建的窗格。
5. 真实案例复盘：我从按键无声到全功能键复活的完整过程
上面讲了一堆理论，可能有些抽象，我直接用一次真实的排查经历把整个过程串起来。
5.1 现象描述
当时我用 PuTTY 0.74 连接一台 Ubuntu 20.04 服务器，在 byobu 里按 F2，预期是水平分割窗格。实际表现是：没有任何反应，屏也不闪，状态栏也没变化。按 F3 创建新窗口，同样没反应。F1 倒是能弹出 help。
5.2 排查第一层：PuTTY 键盘序列
我先在普通 bash 里按 F2，结果显示 ^[OQ。这个结果说明 PuTTY 默认发送的序列没有异常。所以我初步判断问题在 byobu 这一侧。
5.3 排查第二层：byobu 绑定
在 byobu 里按 Ctrl+A 再按 ? 查看键表，发现 F2 的绑定是：
text复制bind-key -n F2 new-window
它居然不是分割窗格，而是新建窗口。这就解释了为什么按 F2 看起来“没反应”——实际上它可能在窗口列表里增加了一个窗口，但我的目光只盯着当前窗格，根本没注意到窗口变化。
5.4 排查第三层：为什么 byobu 的 F2 绑定不是默认常见的分割
我本地的 byobu (5.133) 默认 F2 就是 new-window，只有在某些发行版里才是 split-window -h。这个谜底揭开后，我意识到很多用户说“F2 无效”，其实不是“按键没有被识别”，而是“按键绑定的行为和自己预想的不一样”。
5.5 解决
我选择了按自己的使用习惯重绑 F2：
tmux复制bind-key -n F2 split-window -h
bind-key -n F3 split-window -v
bind-key -n F4 new-window
然后在 ~/.byobu/keybindings.tmux 里保存。重新进入 byobu 后，F2、F3、F4 全部按预期工作。
5.6 额外收获
这个过程中我还顺带发现，F1 在 byobu 里默认绑定的是 help，而这个 help 会启动一个占用终端输入的子进程，在某些 PuTTY 会话里可能显示异常。如果你按 F1 时发现卡住，可以把它也重绑成别的功能。
6. 顺手把 PuTTY 和 byobu 的整体体验调顺：更多值得检查的细节
F2 只是冰山一角。既然已经为这个键折腾了一轮，不如把整个 PuTTY + byobu 组合按我的使用习惯整体调一遍，免得以后按 F5、F6 又撞出莫名其妙的问题。
6.1 PuTTY 窗口大小和 byobu 的布局重排
byobu 开启时会根据终端尺寸计算窗格布局。PuTTY 默认的 80x24 窗口比较窄，如果你在 byobu 里做三四个分割，每个窗格小得没法看。建议在 PuTTY 的 Window -> Columns/Rows 里把默认窗口调大，比如 140x40。改了这个之后，byobu 的 shift+F11 或 Ctrl+A+F11 能重新调整布局，使用体验好很多。
6.2 PuTTY 的编码和 byobu 的 UTF-8 显示
很多人在 PuTTY 里跑 byobu，发现窗格边框是波浪号或者问号。这通常不是 byobu 的问题，而是 PuTTY 没有正确设置为 UTF-8。去 Window -> Translation，把 Remote character set 改成 UTF-8，同时把 Use font encoding 关掉。改完后 byobu 的线条字符才能正常显示。
6.3 PuTTY 的滚动缓冲和 tmux 的滚动模式
byobu/tmux 有自己的一套历史回滚机制，Ctrl+A 然后 [ 进入复制模式，用方向键或 PageUp 浏览。但如果你是在 PuTTY 里直接滚动鼠标滚轮，默认行为可能是滚动 PuTTY 的本地回滚，而不是 tmux 的历史缓冲。要解决这个，可以在 PuTTY 的 Window -> Behaviour 里把 Shift+PageUp 和 Shift+PageDown 保留给 PuTTY 本地，而滚动鼠标滚轮就交给 tmux。也可以在 tmux 里启用鼠标模式：
tmux复制set -g mouse on
这个我一般在 byobu 里用 Ctrl+A + : 临时开启，或者写进配置。
6.4 终端颜色和 byobu 的状态栏颜色错乱
PuTTY 默认使用 16 色，而 byobu 状态栏会用 256 色。颜色不对的时候，状态栏会显得很“糊”，甚至看不清当前窗口名。在 PuTTY 的 Window -> Colours 里把 Allow terminal to specify ANSI colours 勾上，然后在远程的 ~/.bashrc 里设置 TERM=xterm-256color，这样 byobu 会使用 256 色调色板。
6.5 多套连接配置的复用
如果你有多台服务器要连，建议在 PuTTY 里把刚才调好的键盘、颜色、编码设置保存成一个 session，并在 Session 页面里设置 Default Settings。这样以后新建连接时，这些参数会自动带上，不用每台机器重新设一遍。
6.6 考虑用 PuTTY 的 -load 参数为 byobu 专用会话建立快捷方式
既然题目标签里有“putty如何通过快捷方式带参数启动”这样的话题热度，我就多说一句。PuTTY 支持从命令行加载已保存的会话：
bash复制putty.exe -load "my-server"
如果你每次开 PuTTY 都是为了直接进 byobu，可以在远程 shell 的 .bashrc 末尾加一段判断，检测到是交互式登录且没有 byobu 环境变量时自动执行 byobu：
bash复制if [ -z "$TMUX" ] && [ -z "$BYOBU" ] && [ "$PS1" != "" ]; then
byobu
fi
不过要小心，这段判断在普通终端里也会触发，你可能会被迫进入 byobu。我一般只在专门的连接用户目录下加这个，或者配合 putty -load 加一个 -m 参数指向一个脚本，脚本里只执行 byobu。
7. 常见异常变体：F2 无效之外的那些“同病不同源”的情况
排查 F2 问题时，我还遇到过几个看起来和 F2 无关、但实际上同源的状况。如果你按 F2 时也伴有以下表现，那大概率也是同一类问题。
7.1 F2 按下去变成了字符“Q”或者“q”
这个情况说明 PuTTY 发送的序列中，O Q 里的 Q 被终端程序当成普通键处理了，也就是 ESC 丢失或未解析。多发生在 byobu 进入某些特殊模式时，比如你之前按过 Ctrl+A 然后误触了冒号进入命令行输入状态，此时后续按键都被当成编辑命令，F2 自然不生效。解决办法很简单：按 Esc 退出当前模式，再按 F2。
7.2 F2 在 byobu 内是生效的，但会同时触发一个“外部”行为
例如 PuTTY 的 Window -> Behaviour 里设置了 Alt+F2 之类的快捷键，导致 byobu 还没收到 F2，窗口系统先响应了。这个在 Windows 上不常见，但如果你用的是远程桌面再套 PuTTY，可能被远程桌面快捷键拦截。排查时可以把 PuTTY 放到全屏模式，排除窗口管理器干扰。
7.3 F2 在 tmux 里按了之后没有分割，而是进入了“标记窗格”模式
有些 byobu 版本里 F2 绑定的是 display-panes，这个命令会临时显示所有窗格编号，让你按数字跳转。它和分割窗格的行为差异很大。如果你看到按 F2 后屏上出现一堆数字编号，说明 F2 被绑定成了 display-panes，不是失效。想改回分割，需要重绑。
7.4 多版本 byobu 造成的键位漂移
Ubuntu 20.04 自带的 byobu 和 Ubuntu 22.04 自带的版本，F 键绑定有差异。20.04 的 byobu 对 F2 的定义更贴近 tmux 原始风格，22.04 的 byobu 则更贴近 screen 风格。如果你从旧版本跳升后 F2 突然“变了”，先查版本：
bash复制byobu --version
再看对应版本的默认配置文件：
bash复制dpkg -L byobu | grep keybindings
打开文件看 F2 的定义即可。旧配置里的自定义绑定可能和新版本不完全兼容，必要时重置一下 ~/.byobu 下的键位配置。
8. 一条更省心的替代路线：换掉 PuTTY，或换掉终端层
你可能会问：既然问题出在 PuTTY 的功能键协议，那不用 PuTTY 行不行？当然行。虽然题目限定是 PuTTY，但多了解几条路线，有助于你判断“修”还是“换”。
8.1 Windows Terminal + OpenSSH 是个好选择
Windows Terminal 自带 ssh 客户端，功能键序列默认符合 xterm 规范，我实测 byobu 里的 F2 不用任何配置就能用。如果你对 PuTTY 的折腾没有执念，直接用 Windows Terminal 反而最省心。
8.2 WSL 里跑 ssh
在 WSL 的 Ubuntu 里执行 ssh user@server，然后进 byobu，功能键序列走的是 Linux 终端标准，基本没遇到过 F2 失效。缺点是多了一层 WSL 资源占用，但对现代电脑来说完全可忽略。
8.3 MobaXterm 的 Xterm 模拟模式
MobaXterm 内置终端模拟更接近 Linux 终端，F2 默认也正常。它还有图形化 SFTP 面板，适合需要频繁传文件的人。
但“换终端”并不是所有场景都允许。如果公司环境锁定只能装 PuTTY，或者你要连接的是老旧设备只有 PuTTY 能兼容，那还是老老实实用第 3 节和第 4 节的方案调校。
9. 把解决方案固化成一份可复用的检查单
这里是我每次遇到 PuTTY + byobu F 键问题时的固定排查顺序，我直接贴在笔记里，省得下次再从头摸索：
- 确认 PuTTY 版本，看键盘设置是否被改过。
- 在普通 bash 下按 F2，执行
cat -v观察输出序列。 - 确认输出是否为
^[OQ或^[[12~。 - 进入 byobu，执行
Ctrl+A + ?查看 F2 当前绑定。 - 确认绑定是不是你要的行为（分割窗格 / 新建窗口）。
- 如果绑定正确但 F2 无反应，尝试临时执行
byobu-tmux set -g terminal-overrides "xterm*:kf2=\eOQ"。 - 如果临时设置生效，写入
~/.tmux.conf或~/.byobu/keybindings.tmux。 - 如果绑定不对，重绑 F2，并检查是否和其他键冲突。
- 检查 PuTTY 的
Terminal -> Keyboard是否选成Xterm R6。 - 检查 PuTTY 的 translation 编码是否为 UTF-8，防止出现连带乱码。
这套检查单看起来步骤多，但实际跑完只需要两三分钟。关键是第 2 步和第 4 步能帮你快速把问题二分：是按键没到，还是到了没干活。
最后再分享一下个人体会，我在这类远程终端问题上踩过很多次坑，最大的感受是：不要一上来就怀疑软件出 bug。PuTTY 和 byobu 都是非常成熟的工具，绝大多数“失效”都只是按键序列或者配置语义不匹配。顺着链路一层层看，每个环节用最小代价验证一下，问题都会现形。如果你只是想要一个能用的环境，直接重绑 F2 和 F3 到常用分割命令，并把 PuTTY 键盘模式设为 Xterm R6，这一套组合基本能让你忘掉今天踩过的坑。