清风输入法混输
五笔优先、拼音兜底的融合策略——候选来源、上屏否决、触发长度，以及混输为何没有自己的词库
方案 → 混输。混输是「码表优先、拼音兜底」的融合引擎：输入编码时同时匹配码表和拼音，码表结果排在前面，忘记编码时用拼音也能打出来。内置的五笔拼音（ID wubi86_pinyin）就是这类。
wq → 你（五笔匹配）
nihao → 你好（拼音兜底）融合策略是全局唯一配置，无方案级覆盖，对应 config.toml 的 [schema.mix] 段。完整键名与默认值见方案与引擎配置。
混输方案自己没有词库
这是理解混输最关键的一条：混输方案不拥有任何词库。它的方案文件里没有 [[dictionaries]] 段，只声明「我由谁组成」：
[engine.mixed]
primary_schema = "wubi86" # 主方案（码表）——码表候选与码表词库都来自它
secondary_schema = "pinyin" # 辅助方案（拼音）——拼音候选与拼音词库都来自它这两个字段不只决定候选来源，也决定词库来源：混输里出现的每一个候选，都出自这两个被引用方案的词库，混输本身只负责把两路候选融合、排序、竞争上屏。
由此得到两条实用推论：
- 要给混输加词库、开关扩展词库，得去码表方案或拼音方案上改——混输的方案设置对话框里没有任何词库项。改完对原方案与混输同时生效
- 在五笔方案下造的词、导入的用户词库，切到混输立刻能用；反过来也一样。它们本就是同一份数据，不存在「同步」这回事
也因此，主拼音方案那一项管不到混输——混输用哪个拼音由它自己的 secondary_schema 决定。
用户数据归到哪个方案
既然词库是借来的，用户数据也随之分流。混输下产生的数据按候选来源记账：
| 数据 | 归属方案 |
|---|---|
| 用户词库、临时词库、词频（码表候选） | 主方案 wubi86 |
| 用户词库、临时词库、词频（拼音候选） | 拼音方案 pinyin（全拼与双拼共用同一份） |
| 候选调整（置顶 / 隐藏） | 混输方案自己 |
调频与自动造词的开关也跟着子方案走——码表侧读码表那张卡，拼音侧读拼音那张卡，混输没有自己的一套。
为什么只有候选调整留在混输名下
候选调整针对的是融合之后的候选顺序——「在混输里把这个候选置顶」这句话，只有在混输这个上下文里才有意义，放到纯五笔或纯拼音下并不成立。其余三类数据的归属都能由候选来源唯一确定，于是直接落到子方案。
这也是词库页选中混输方案时只有「候选调整」一类的原因——不是功能缺失，是别的数据本就不在这里。
开启「启用英文候选」后混进来的英文候选归码表侧记账，与码表候选同一个方案 id。
候选来源
下表各项在卡片里分属「混输行为」与「拼音相关」两个小标题。
| 选项 | 说明 | 出厂 |
|---|---|---|
| 显示候选来源标记 | 候选旁标出它来自码表还是拼音，方便初学者辨认 | 关 |
| 启用英文候选 | 同时查询英文词库并显示英文候选；各项细调在它的 扩展设置 对话框里（见英文候选的细调） | 关 |
| 启用拼音简拼 | 拼音侧是否产出简拼候选（nh → 你好） | 关 0.117 新增 |
| 拼音候选显示编码 | 显示「当前：模板名」，即候选注释分配里混输方案的默认态；点旁边「去设置」跳到 外观 › 候选注释 修改，可选码表编码 / 剩余编码 / 编码（自动）/ 不显示等。编码反查：用拼音打出的字词，旁边显示它的码表编码（打 nihao，「你好」旁显示 wqvb），方便记码。出厂「码表编码」；只管混输方案，与拼音方案、临时拼音的分配互不影响。0.129 前是独立开关，旧值不迁移 | 显示码表编码 0.125 新增 |
| 拼音最小触发长度 | 编码达到此长度才开始查拼音（0 = 跟随默认值 2，即 1 码不查拼音） | 2 |
| 显示拼音前缀匹配 | 码长以内，只有编码开头能读成拼音时（gedw 的 ge），是否也列出这些只解释了一部分编码的拼音候选。关着时 gedw（五笔「青春」）不会再带出 ge 的两百多个同音字；代价是码长内不能先选一段上屏、剩余接着打。正在打的拼音不受影响：wanl →「完了」照常出 | 关 0.117 新增 |
| 超码长时显示拼音前缀匹配 | 编码超过主码表最大码长、进入纯拼音语境后同上。开着才能分步上屏：nihaom 先选「你好」，再接着打 ma | 开 0.117 新增 |
启用拼音简拼
出厂关。简拼会让几乎任何字母串都可能被解释成拼音，在混输这种「每个字母都可能是五笔码」的场景里尤其吵；关着时拼音只认全拼，候选更干净，而且顶码上屏才用得起来（见下）。
它只影响混输的拼音子引擎，纯拼音方案不受影响。
- 反过来，混输要出简拼还需拼音 · 关闭简拼里的「启用简拼」开着（出厂开），两个都开才出 0.125 新增
英文候选的细调 0.128 新增
「启用英文候选」一行的 扩展设置 对话框（方案 → 混输 → 启用英文候选 → 扩展设置）里，各项与码表的英文候选同口径：
| 选项 | 说明 | 出厂 |
|---|---|---|
| 英文补全最小码长 | 有中文候选时，编码达到此长度也按前缀补全英文（设 4，打 gith 出 github）；0 = 只在没有中文候选时补全 | 0 |
| 英文单词最前位置 | 整串恰好是英文单词时，英文最靠前排第几位；仍先让过开头的完整匹配中文，只会更靠后 | 1 |
| 英文补全最前位置 | 前缀补全出来的英文最靠前排第几位；总在英文单词之后 | 2 |
| 英文最多条数 | 有中文候选时英文最多显示几条（完整单词优先）；没有中文候选时不受此限 | 2 |
| 有英文候选时否决上屏 | 前缀级，见下文上屏否决策略 | 关 |
| 整串是英文单词时否决上屏 | 成词级，见下文上屏否决策略 | 开 |
混输里的英文还有几条行为：
- 码表和拼音都没有候选时，英文给前缀补全（不受「最多条数」限制），与输入相同的英文词排最前。
- 候选被截断时，英文有保底座位（至多「英文最多条数」条），不会被拼音候选挤掉。
- 整串恰好是一个英文单词时，默认不满码上屏、不顶码（成词级否决），打完
github不会被中文顶走。
上屏否决策略
混输最微妙的部分：码表侧想自动上屏（满码、顶码），但拼音或英文侧可能还有更好的答案。下面这些开关（拼音两项在卡片的「上屏设置」小标题，英文两项收进了「启用英文候选」的扩展设置）决定什么时候该拦住码表：
| 选项 | 说明 | 出厂 |
|---|---|---|
| 有拼音候选时否决上屏 | 只要整串还能查出拼音候选就不自动上屏（不看拼音是否成词） | 见下 |
| 整串是拼音词时否决上屏 | 整串是完整拼音、且拼音首选是真实词时才拦（如 wangba → 网吧） | 见下 |
| 有英文候选时否决上屏 | 前缀级：满码自动上屏与顶码上屏前，只要有英文词以当前编码开头就不上屏；开启时已涵盖下一项。仅启用英文候选时有效。0.128 起这一项从「上屏设置」挪进了「启用英文候选」的扩展设置 | 关 |
| 整串是英文单词时否决上屏 0.128 新增 | 成词级：整串恰好是一个英文单词时才拦（英文临时词不算），英文词的前缀不拦。仅启用英文候选时有效 | 开 |
英文那一对是同样的结构（前缀级对成词级）。两个拼音拦截的差别在判据松紧：
- 「有拼音候选时否决」最严，几乎任何字母串都能凑出拼音候选，等于关掉了自动上屏
- 「整串是拼音词时否决」只在拼音真的拼出一个词时才拦：
wangba→ 网吧 会拦，aipu→ 落实（拼音侧凑不出强词）照常上屏
顶码上屏有一个例外
第一项虽然最严，但顶码上屏时如果「归属已判给码表」——前 N 码是码表精确全码，而拼音和英文都解释不了整串——它就不再否决。
例：打 cety（唯一全码「通往」）再按第 5 键，ce 是完整音节但 ty 构不成音节，拼音只解释了 5 键里的 2 键，于是照常顶出「通往」。第二项不享受这个例外。
打开「启用拼音简拼」会让顶码上屏基本失效
简拼开着时，简拼候选会「消费整串」，超码长的归属就恒判给拼音，顶码上屏基本不会发生——这两个否决开关都关掉也没用（真正拦截的那一项在设置页里是隐藏的）。
这就是「启用拼音简拼」出厂为关的原因。反过来，若让简拼不算「主张整串」，简拼长词就会被五笔顶码截胡，所以做成了两类用户各取所需：默认让顶码可用，需要简拼打长词的显式打开并接受失去顶码。
第一项还兼管「满码空码清空」
「有拼音候选时否决上屏」开启时，满码无匹配也不清空缓冲（因为拼音可能还没打完）；关闭则满码无匹配即清空。这是一个开关管两件事，改它之前留意一下。
五笔为何总排在前
混输的「码表优先」不是靠上面这些开关，而是由引擎内建的来源档位保证，无需也无法配置：
码表精确全码 → 码表前缀补全 → 拼音这是层间隔离机制：把整个码表层压在拼音字之前，让码表编码即便与拼音冲突也稳定靠前。 档位是结构性的，与词频无关——一个字的词频再高也不会因此跨过档位。
适用人群
- 五笔初学者：主用五笔，忘码时直接打拼音过渡
- 偶尔忘记编码的五笔用户：不必切方案或触发临时拼音
相关页面
对这篇文档有疑问，或发现内容有误？
欢迎到文档仓库提 issue，写明问题时附上本页链接即可。