同一个词，在两个软件里排第几
先看一个具体的现象。输入拼音 shishi，在聊天窗口里候选栏前三可能是「试试」「事实」「实施」；切到代码编辑器里，同样输入 shishi，前三可能变成「实事」「时时」「试试」。「试试」从第一掉到第三。
再看一个更明显的。输入 key，在浏览器地址栏里，候选栏第一往往是英文 key；在中文文档编辑器里，同一串输入第一可能是「可以」。
这些差异不是随机的。每次输入，输入法都会现场算一遍排序分。分三个来源：字母组合能对应哪些词，当前上下文支持哪个词，当前场景下哪个词库权重更高。三处任一变化，顺序就会变。
用户感知到的「这个软件里输入法更好用」，通常指的是输入法在这个软件里拿到了更多信息，排序更贴近用户预期。反过来，「这个软件里输入法很笨」，多数是输入法在这个软件里能拿到的信息太少。
输入法怎么知道自己在哪个软件里
输入法要做的第一件事是识别前台窗口。这个能力由操作系统提供，Windows 上走的是文本服务框架（TSF）或更老的输入法管理器（IMM）接口。
通过这些接口，输入法能拿到几类信息：前台窗口的进程名、窗口类名、窗口标题，以及编辑框的属性和光标位置。进程名决定场景分类——chrome.exe 归浏览器，Code.exe 归代码编辑器，WeChat.exe 归即时通讯。
光标位置是另一条重要信息。输入法需要知道光标在哪，才能把候选栏放在正确位置。如果应用不给光标坐标，候选栏只能回到屏幕默认位置。这也是为什么某些全屏游戏里的候选栏会固定在角落。
编辑框属性会告诉输入法这个框是普通文本框，还是密码框、还是只接受数字。密码框会触发特殊处理，候选栏不显示候选内容，防止截屏泄露。
问题出在，这套接口不是强制实现的。搜狗输入法能拿多少信息，取决于应用给了多少。应用可以选择只提供最基本的接口，不返回光标坐标，甚至完全绕过系统输入法接口自己处理键盘输入。
场景词库：不同应用类型权重不同
拿到应用类型后，输入法会调整词库权重。同一份词库，在不同场景下给不同的词加权。
在聊天软件里，语气词、表情相关词、网络用语的权重会抬高。在代码编辑器里，英文标识符、常见编程词汇的权重抬高，中文语气词的权重下降。在表格软件里，数字、日期、单位符号的权重更高。
这套加权不是硬切换，是叠加在基础词频之上的调整。基础词频来自通用词库和用户个人词库，场景权重作为修正项参与打分。一个词在通用词库里的基础分不变，但加了场景修正之后，在不同应用里的最终得分不同。
场景分类的颗粒度有限。输入法能区分的是「浏览器」「编辑器」「聊天工具」这类粗分类，无法精确知道用户此刻在写什么。写代码的时候也可能需要输入中文注释，写文档的时候也可能需要输入英文术语。粗分类的代价就是有些场景下的加权不符合用户当下的真实需求。
一个容易观察到的现象：同一个词，你第一次在聊天软件里选中它，排序会记住；切到编辑器里用同一个词，需要重新选一次。因为两边的场景权重不同，学习结果被记在各自的场景下。
上屏路径差异：TSF 和 IMM 两条路
Windows 上有两套输入法接口，TSF 是新的，IMM 是旧的。新应用大多走 TSF，老应用、部分游戏和自绘文本框可能仍走 IMM，或者两者都不走。
两条路径下，输入法能拿到的信息不一样。TSF 支持更细的上下文查询，能拿到光标前后的文本；IMM 能拿到的信息少得多，通常只有基础的光标位置。走 IMM 的应用里，输入法的上下文判断能力会明显下降。
还有一部分应用完全绕过系统接口，自己实现文本输入。比如很多游戏用 DirectInput 或自绘 UI，键盘事件在应用内部处理，输入法只负责把候选结果送过去。这种情况下，输入法既拿不到上下文，也拿不到光标位置，排序只能靠字母组合和通用词频。
| 应用类型 | 接口路径 | 可获取上下文 | 光标位置 | 场景加权 |
|---|---|---|---|---|
| 现代桌面应用 | TSF | 完整 | 准确 | 生效 |
| 老式应用 | IMM | 部分 | 基本准确 | 生效但依据少 |
| 自绘文本框 | 绕开系统接口 | 无 | 无或粗略 | 仅按进程名 |
实测：同一输入在五个应用中的排名差异
下面的数据为人工构造，测试环境为 Windows 11 24H2、16.8 正式版、默认词库、关闭云输入，同一台设备上依次在五个应用中输入同一串拼音，记录目标词在候选栏中的位次。样本量小，数据仅供说明差异的存在，不代表精确排名。
| 应用类型 | 目标词位次 | 相比基准的偏移 | 主要影响因素 |
|---|---|---|---|
| 聊天软件 | 第 1 位 | 基准 | 场景加权偏高 |
| 浏览器输入框 | 第 1 位 | 0 | 上下文完整 |
| 文档编辑器 | 第 2 位 | +1 | 场景加权不同 |
| 代码编辑器 | 第 3 位 | +2 | 英文词权重抬高 |
| 全屏游戏 | 第 4 位 | +3 | 无上下文信息 |
为什么有些软件里候选顺序完全不按套路
当输入法拿不到上下文信息时，排序退回到只依赖字母组合和通用词频。这时的顺序看起来「不按套路」，其实是信息不足导致的退让。
退让后的排序有几个特征。短词优先级下降。日常高频的短词在通用词频里排得靠后，因为缺少上下文支持。用户会觉得「这个词我天天打，怎么不排前面」。同音词无法区分。同一个拼音对应多个词时，只能按通用词频排，不考虑当前语境。场景加权只按进程名生效。如果连进程名都拿不到，场景加权也不生效，所有应用退回同一套排序。
还有一类特殊现象是候选栏位置异常。输入法拿不到光标坐标时，候选栏会跑到屏幕角落或窗口边缘。这时用户看到的不只是顺序变了，连候选栏本身都不在预期位置。
用户能控制的三个变量
跨软件差异没法完全消除，但用户有三个可调的变量。
用户词库。某个词你在某个软件里反复用，输入法会记住。这个记忆跟场景绑定，同一软件里下次排序会更靠前。代价是需要在每个软件里各选一次。
场景词库开关。如果关闭场景词库加权，所有应用退回同一套词频排序。顺序会趋向统一，但代价是失去场景适配——写代码时不再优先给英文词，聊天时不再优先给语气词。多数用户不值得做这个交换。
词库更新。通用词库的更新会改变基础词频。新版本调整了某些词的权重，排序也会变。这跟软件无关，是全站生效的变化。
三个变量里，实际可操作的主要是第一个。用户在具体软件里纠正几次排序，输入法会逐渐适应该软件的使用习惯。这是本地学习行为，不需要联网。
跨软件差异做不到什么
不能让所有软件顺序一致。顺序依赖应用给的上下文信息，这些信息由应用决定。输入法无法强制应用提供更多信息，也无法在信息缺失时凭空推断。想让顺序完全统一，只能放弃场景适配能力。
不能推断软件里在写什么内容。输入法知道的是「这是浏览器」，不知道「用户在写邮件还是在搜索」。粗分类能覆盖的场景有限，细分场景需要应用主动提供更多信息，这在接口层面没有标准。
不能解决自绘文本框的问题。完全绕开系统接口的应用，输入法只能送候选结果，排序和候选栏位置都无法与系统行为一致。这是接口层面的限制，输入法侧没有解决办法。
不能保证同一个词在同一软件里永远同一位次。排序还受上下文、用户历史、词库更新影响。今天的位次和一个月后的位次可能不同。差异是常态，不是异常。
关于候选词排序差异的常见问题
下面 5 个问题是读者反馈中最常被问到的
为什么同一个词在不同软件里排序不同？
主要来自三处差异。一是输入法从软件拿到多少上下文信息，不同软件对输入法接口的支持程度不一样；二是场景词库权重，输入法会根据应用类型给不同词库加权；三是软件自身的文本处理方式，部分软件会干扰光标位置或屏蔽接口。三者叠加，同一串输入在不同软件里能得到不同的候选顺序。
候选词排序是固定规则吗？
不是。排序是打分结果，分数由词频、上下文、场景权重、用户习惯共同决定，任何一项变化都会改变顺序。同一个词库、同一台设备，只要切换应用，场景权重就变了，顺序也会跟着变。
为什么在游戏里候选栏不跟着光标走？
多数游戏用全屏渲染和自绘文本框，不走系统的输入法接口，输入法拿不到光标坐标。候选栏只能回到默认位置，通常屏幕左下角或右下角。这是接口层面的限制，输入法侧无法解决。
能不能让所有软件的候选顺序统一？
不能完全统一。输入法的排序依赖应用提供的上下文信息，这些信息由应用决定给不给、给多少。只有关闭场景词库加权、只用固定词频排序，顺序才会接近统一，但这样会牺牲场景适配能力。代价大于收益。
关闭场景词库后跨软件差异会消失吗？
会缩小，但不会消失。场景权重只是差异来源之一。接口支持程度、光标信息、软件自绘文本框这些因素仍在，部分软件里候选顺序依然跟其他地方不一样。关闭场景词库主要影响的是常规应用之间的顺序差异。