混输方案配置

五笔优先、拼音兜底的融合策略——候选来源、上屏否决、触发长度，以及混输为何没有自己的词库

方案 → 全局方案配置 → 混输方案配置。混输是「码表优先、拼音兜底」的融合引擎：输入编码时同时匹配码表和拼音，码表结果排在前面，忘记编码时用拼音也能打出来。内置的五笔拼音（ID wubi86_pinyin）就是这类。

wq    → 你（五笔匹配）
nihao → 你好（拼音兜底）

融合策略是全局唯一配置，无方案级覆盖，对应 config.toml 的 [schema.mix] 段。完整键名与默认值见方案与引擎配置。

混输方案自己没有词库

这是理解混输最关键的一条：混输方案不拥有任何词库。它的方案文件里没有 [[dictionaries]] 段，只声明「我由谁组成」：

[engine.mixed]
primary_schema = "wubi86"       # 主方案（码表）——码表候选与码表词库都来自它
secondary_schema = "pinyin"     # 辅助方案（拼音）——拼音候选与拼音词库都来自它

这两个字段不只决定候选来源，也决定词库来源：混输里出现的每一个候选，都出自这两个被引用方案的词库，混输本身只负责把两路候选融合、排序、竞争上屏。

由此得到两条实用推论：

也因此，主拼音方案那一项管不到混输——混输用哪个拼音由它自己的 secondary_schema 决定。

既然词库是借来的，用户数据也随之分流。混输下产生的数据按候选来源记账：

调频与自动造词的开关也跟着子方案走——码表侧读码表方案配置，拼音侧读拼音方案配置，混输没有自己的一套。

为什么只有候选调整留在混输名下

候选调整针对的是融合之后的候选顺序——「在混输里把这个候选置顶」这句话，只有在混输这个上下文里才有意义，放到纯五笔或纯拼音下并不成立。其余三类数据的归属都能由候选来源唯一确定，于是直接落到子方案。

这也是词库页选中混输方案时只有「候选调整」一个子标签的原因——不是功能缺失，是别的数据本就不在这里。

开启「启用英文候选」后混进来的英文候选归码表侧记账，与码表候选同一个方案 id。

关掉后混输里的拼音只认全拼，候选更干净——简拼会让几乎任何字母串都可能被解释成拼音，在混输这种「每个字母都可能是五笔码」的场景里尤其吵。

它只影响混输的拼音子引擎，纯拼音方案不受影响。

混输最微妙的部分：码表侧想自动上屏（满码、顶码），但拼音侧可能还有更好的答案。这三个开关决定什么时候该拦住码表：

选项	说明	出厂
有拼音候选时否决上屏	只要整串还能查出拼音候选就不自动上屏（不看拼音是否成词）	见下
整串是拼音词时否决上屏	整串是完整拼音、且拼音首选是真实词时才拦（如 `wangba` → 网吧）	见下
有英文候选时否决满码上屏	满码自动上屏前若存在英文候选（含前缀）则不上屏；仅启用英文候选时有效	——

两个拼音拦截的差别在判据松紧：

第一项还兼管「满码空码清空」

「有拼音候选时否决上屏」开启时，满码无匹配也不清空缓冲（因为拼音可能还没打完）；关闭则满码无匹配即清空。这是一个开关管两件事，改它之前留意一下。

混输的「码表优先」不是靠上面这些开关，而是由引擎内建的来源档位保证，无需也无法配置：

码表精确全码  →  码表前缀补全  →  拼音

这是层间隔离机制：把整个码表层压在拼音字之前，让码表编码即便与拼音冲突也稳定靠前。档位是结构性的，与词频无关——一个字的词频再高也不会因此跨过档位。

0.x 版本曾有一个 codetable_weight_boost 配置项

早期这套档位是用「给码表候选的词频加一个大常数」实现的，方案文件里因此有一项 codetable_weight_boost。它已改为显式档位，配置项随之下线。老方案文件里残留该行不影响加载，会被静默忽略。