这个系列想解决什么

我用 Linux 的日常是这样一条链路：

键盘 → 内核 → X11 / AwesomeWM → WezTerm → fcitx5-rime → tmux → zsh / Neovim

每一层都有自己的键位配置，每一层都能"吃掉"一个按键。配置攒了十几年，散落在 ~/.Xmodmap、rc.lua、wezterm.lua、.tmux.conf、.zshrc、options.lua、 default.custom.yaml 里。单看每个文件都能读懂，但连起来经常回答不了这类问题：

• 我按了 Alt+b，为什么中文状态下 tmux 收不到？
• Ctrl+i 和 Tab 在 Neovim 里为什么绑不开？
• 从 macOS ssh 过来 attach 同一个 tmux session 之后，本机的输入法自动切换为什么坏了？
• 明明 xmodmap 配好了，插上外接键盘就失效？

这个系列把这些经验重新梳理一遍，目标是从物理层一路讲到应用层，让上面这些问题 都能有确定的答案，而不是靠试。

一条不太一样的评价标准

谈快捷键，最常见的评价标准是"少按几个键"。这个标准很容易度量，但它解释不了为什么 有些"很省键"的配置用起来反而累。

这个系列用的标准是另外三条：

一、保护注意力。 手离开主键区去够方向键、去看鼠标在哪，代价不是那几百毫秒， 而是思路被打断。一个键位设计得好不好，看的是它有没有让你在"想做的事"和"怎么做到" 之间反复切换。

二、减少状态确认。 模态编辑器、输入法、tmux 的 prefix、终端的 copy-mode，都是 状态机。每次"我现在在什么状态？"的自我确认，都是一次注意力开销。好的设计要么让状态 在视觉上一眼可辨，要么干脆让状态自动回到你需要的那个——比如离开 Neovim 插入模式时 自动把 rime 切回英文，你就永远不需要低头看输入法指示器。

三、降低错误恢复成本。 按错键之后要花多久回到原处，比按错的概率更重要。在正常 模式下误触了中文逗号 ，，如果它直接当成 leader 键 , 生效，那就没有"错误"需要 恢复；如果它插入了一个全角字符再报错，就得撤销、切输入法、重来。

后面每一篇的配置取舍，都会回到这三条上。

四个核心问题

整个系列围绕四个问题展开：

1. 按下一个键，从物理层到应用层到底发生了什么？ 键盘矩阵扫描、USB HID、内核 input 子系统、X11 keycode/keysym、终端字节流。 对应第 1–3 篇。

2. ssh / awesome / wezterm / tmux / zsh / nvim 组合环境下，一个快捷键被谁捕获、 按什么顺序处理？ 这是所有"快捷键冲突"问题的总纲。对应第 6 篇，第 4–5 篇打基础。

3. zsh / wezterm / nvim 三处"自动切换 rime 中英文"是如何实现的，底层原理是什么？ 三个位置、三种触发时机、同一个 D-Bus 接口，以及 tmux 多 client 场景下的归因难题。 对应第 12 篇。

4. 怎样设计一套不迫使用户反复确认状态、不中断心流，而且能长期维护的键位系统？ 第 7–11 篇逐层示范，第 13 篇收束成可操作的原则。

目录

第一部分：一个按键的完整旅程

第二部分：重塑键盘

第三部分：谁拿到了这个键

第四部分：输入法与收束

阅读方式

每一篇都可以独立读。如果只关心某个具体问题：

• 想弄懂"这个键去哪了" → 第 1、6 篇
• 想改键（Caps 换 Ctrl 之类）→ 第 4、5 篇
• 终端里绑不上某个组合键 → 第 3 篇
• 输入法老是切不回来 → 第 12 篇
• 想重新设计自己的键位 → 第 13 篇

环境说明

文中所有实例来自我的实际环境，配置文件都在公开仓库里：

配置仓库：

• dotconfig：awesome / wezterm / tmux / zsh / xmodmap / udev / rime
• nvim：Neovim 配置