前段时间在 Ghostty 里用中文输入法时发现，光标停在文字中间打中文，后面那个字会一个接一个消失。跟覆盖模式、跟什么切换快捷键都没关系，一直没有找到原因，昨天实在受不了了，专门花了几分钟来试了下，最终发现：
微信输入法的「中文与英文/数字之间自动加空格」补完那个空格之后，又替终端发了一个 Delete ； Ghostty 按物理键码解释这个事件，下发的就是"删掉光标右边一个字符"。 所以只有 Ghostty 掉字，iTerm2 、TextEdit 、Sublime 、Tabby 都正常。
但是在行尾打就不会出事，多打几个空格把位置占出来也不会，可有时候怎么打都没事。为了这个"时好时坏"，我一开始以为是某个快捷键的问题，还到处去找的那个以为的切换键，结果根本没有这么个东西。
后来换输入法一试就清楚了：百度五笔完全正常，微信输入法必现。
两者唯一的差别就是自动加空格。这个空格要生效，终端得把光标周围的文本告诉输入法。kitty 不告诉，所以在 kitty 里这功能一个空格都不加； Ghostty 和 iTerm2 告诉，空格就来了。
猜不出来，我写了个三十行的小工具，在 Ghostty 里裸读 stdin ，把每个字节按十六进制记下来。
复现序列：先打 12345678，左箭头按四次，打 dd，切中文打 在在，最后再打一个 d。
关键的几行：
e5 9c a8 20 "在 " 一次提交（自动空格）
20 64 " d" 一次提交（自动空格）
1b 5b 33 7e CSI 3~ ← 32ms 后，我没按
1b 5b 33 7e CSI 3~ ← 27ms 后，我没按
同一次测试里我自己按退格，进来的是裸的 7f，跟 1b 5b 33 7e 不同源。最终缓冲区是 1234dd 在在在 dd678，5 真没了，不是显示问题。
通过 AI 分析，macOS 上 117 号键码是 Delete （前向删除），Ghostty 的键码表把 117 映射到内部 delete ，编码成 CSI 3 波浪号。它判断"你按的哪个键"用的是物理键码，事件里那个 7f 文本不参与。AppKit 的原生文本视图反过来，用 characters 字段查键位绑定，7f 落到 deleteBackward ； Tabby （ Electron ）直接把控制字符丢掉。同一个事件里，只有按物理键码解释的那个会去删右边的字。
Ghostty 这边其实有一道防护 shouldSuppressComposingControlInput，但它只拦"组字中"且"字符小于 0x20"的情况。这次的删除发生在上屏之后、带的是 0x7f，两个条件都不满足，就漏过去了。
日志重放一遍还能看出为什么时好时坏：第一次 Delete 落下时，光标右边正好是上一次提交留下的空格，吃掉的是空格，屏幕上没感觉；第二次右边是 5，就少一个字。所以掉不掉，只看光标右边那个位置是不是空格。那个"多打几个空格留位"的偏方，也就是把要被吃掉的东西提前摆好了。
关掉微信输入法的「中文与英文/数字之间自动加空格」，或者换个没这特性的输入法，就没有这个问题了。
准备去 github 提个 issue ，发现在 10 月 16 号已经有人提过同症状的讨论（微信输入法下光标前移再打中文会覆盖后面的文字），零回复。应该还没有处理了，先给贴个过程证据，希望早上修复，可围观： https://github.com/ghostty-org/ghostty/discussions/14732#discussioncomment-19284249
有同样问题的可以回个帖，我把探针脚本贴上来，你自己跑一遍就知道是不是同一个原因。
Select Language