这一天折腾得不轻。卓影·五笔 M7 阶段（自绘候选窗）验收推进到真机环节，故障像剥洋葱一层层露出来：先是候选文字旁橙色圆角矩形边缘的锯齿；锯齿修完，状态条又开始逐帧闪烁；闪烁的三道修复闸部署完，输入法干脆彻底罢工——字母敲下去直接上屏，服务端进程却明明活着。三件事事后串起来是一条完整因果链，复盘如下，权当避坑指南。
文章源自瑾煜博客-https://blog.sjinyu.com/programming/my-software/288.html
一、链头：候选框圆角锯齿（M7 验收第一轮）文章源自瑾煜博客-https://blog.sjinyu.com/programming/my-software/288.html
现象：候选窗里橙色圆角背景与高亮色块边缘呈阶梯状锯齿。文章源自瑾煜博客-https://blog.sjinyu.com/programming/my-software/288.html
根因：自绘候选窗用 Tk 画布渲染，Tk 多边形绘制天生没有抗锯齿，圆角弧线每个像素非黑即白，锐利转折全数裸露。文章源自瑾煜博客-https://blog.sjinyu.com/programming/my-software/288.html
修复：引入 Pillow——圆角背景与高亮块按 4 倍超采样绘制，再用 LANCZOS 算法缩回原尺寸，得到真抗锯齿边缘；Pillow 缺失时回退画布多边形。文章源自瑾煜博客-https://blog.sjinyu.com/programming/my-software/288.html
伏笔：这一修把背景与高亮块从「画布直绘」改成「位图生成 + 贴图重绘」，渲染路径彻底变了。外观解决的同时，渲染频率与帧内容差异被放大——为下一场故障搭好了舞台。文章源自瑾煜博客-https://blog.sjinyu.com/programming/my-software/288.html
文章源自瑾煜博客-https://blog.sjinyu.com/programming/my-software/288.html
二、链条中段：状态条逐帧闪烁（锯齿修复后浮现）文章源自瑾煜博客-https://blog.sjinyu.com/programming/my-software/288.html
现象：打字时编码区与候选列表逐帧跳动，长数字串输入时状态条一格格「生长」式闪动，F4 提示一闪一灭，方向键选词时高亮也在跳。文章源自瑾煜博客-https://blog.sjinyu.com/programming/my-software/288.html
根因：日志取证实锤，每颗按键实际跑了两条刷新链路：文章源自瑾煜博客-https://blog.sjinyu.com/programming/my-software/288.html
- keydown 链：F4 提示插件（processor 链第 4 位）先跑，把提示写进旧段的 prompt 字段；随后 editor 组件落键、重建组词——刚写的 prompt 被整体擦掉，这一帧没有提示；
- keyup 链：抬起不再触发组词重建，提示写进当前段并留存，这一帧带着提示。
两帧交替出帧即逐帧闪烁。雪上加霜的是第三条链路——光标位置更新（UPDATE_INPUT_POS）每次到达还做一次全量重绘，进一步放大跳动。
修复：三道闸依次落位。
- 提示属性化：提示不再挂段（prompt 会随组词重建被擦），改挂上下文属性 zy_f4_hint_text，属性在重建中天然留存，三条链路读到内容恒一致；
- 位置链只挪窗：光标更新只重算窗口坐标，不触发内容重绘，内容变化一律归按键链；
- 渲染签名去重：渲染前先生成内容签名（编码、候选、页码等打包比对），签名未变直接跳过重绘。
教训：输入法前端的「每一次刷新」都不便宜，能合并的链路必须合并，能跳过的重绘必须跳过。而「上一帧有、下一帧没有」的根源，往往是状态挂在了会被重建擦除的结构上。
三、链尾：彻底无法打字（闪烁修复部署期间引爆）
第一层：服务端管道僵死。 字母开始直通上屏后查日志：服务端进程活着、互斥体握在手里、日志停在最后一个焦点事件——管道侧彻底僵死。TSF（Windows 文本服务框架）六连重连每次拉起新实例都被老实例互斥体挡在门外，死锁。此时重启多少次服务端都没用——TSF 已放弃重连，必须重启 TSF 宿主（ctfmon）或重新激活输入法才能触发会话重建。
第二层：取证日志引爆的连锁瘫痪（本次最大坑）。 第一层恢复后打字依旧不通。逐层加取证日志，其中一行 style 首发记录把 self._log 写在了 Responder 类里，而该方法只存在于服务端主类。一个笔误引爆整条链：
- 每次 TSF 申请会话、服务端构造首发响应时必然抛
AttributeError； - 管道处理线程的异常保护只捕
RimeError，AttributeError直接穿透——线程当场死亡、管道随之关闭； - TSF 侧症状成了一个固定指纹：START_SESSION 疯狂重发（每秒数次）、所有消息会话号全 0、零回声验证、零按键转发——它永远拿不到会话 id，按键被放行直通；
- 更糟的是 pythonw 无控制台，异常栈写不进日志，服务端表面一切正常，故障无痕。
排查历程：先加「事务级日志」打出 TSF 每步动作，确认指纹；再写模拟 TSF 的最小客户端对服务端做管道往返——START_SESSION 发出后 WriteFile 成功，ReadFile 却报 ERROR_NO_DATA (233)，即「管道正在关闭」——服务端处理线程死于异常实锤。回代码顺调用链看，五分钟定位那行错引用。
修复两道：
- 改正引用：
self._log→self.server._log； - 异常保护全兜底：处理线程异常捕获从「只捕 RimeError」改为「捕获一切 Exception」，任何异常记全日志（含调用栈）、回空响应，线程不死、管道不关。「UI 任何异常绝不阻断协议链路」本是卓影铁律，这次用真机代价验证了它的分量。
四、避坑指南（浓缩版）
- 验收链上的修复会改变渲染路径，必须连带回归。修锯齿动的是背景绘制，闪出来的却是内容刷新——每改一处，此前验收过的场景都要重跑。
- 加日志也是改代码。取证日志与功能代码同一审查标准，一个错引用能瘫痪整个输入法。
- 协议层异常保护必须 except Exception 兜底。只捕特定异常等于没有保护——穿透异常杀线程、关管道，客户端看到的是「服务端反复拒绝」，极易带偏排查方向。
- 认识 TSF 死态指纹。会话号全 0 + 狂发 START_SESSION + 零 ECHO + 零按键 = 客户端拿不到会话 id；先查服务端响应链路，再查 TSF 状态机，最后才重启 ctfmon。
- ERROR_NO_DATA (233) 是金钥匙。模拟客户端「写成功、读报 233」直接指向服务端处理线程已死，比任何猜测都快。
- 模拟客户端是输入法前端标配诊断工具。不依赖真机按键与 TSF 状态机，一次管道往返验证协议全链路，建议常备。
- 状态要挂在不会被重建擦除的地方。诡异跳动先查挂载点是否位于会被组件重建清空的容器。
五、结语
一条验收链，三个故障：锯齿来自绘制手段的能力边界，闪烁来自状态挂载点选错，瘫痪来自笔误穿透异常保护。症状交叠，区分靠日志指纹：锯齿看边缘像素，闪烁看「两帧内容是否交替」，打不出字看「会话号是否全 0」。指纹记牢，同症再遇十分钟内可定位。
最后照例自省：M7 的每轮真机反馈都在把产品往台面上推，但打字链路是输入法的生命线——往这条线上加任何东西，哪怕只是修复一颗锯齿、插一行日志，都要存一分敬畏。
