开源中文输入法技术调研与自建方案-育师

背景：商业输入法普遍存在数据上传/隐私争议，目标是在纯开源基础上开发一个数据完全本地、无遥测的中文输入法。
还有，是不是怀疑自己输入的数据被备份上传呢，特别讨厌每天广告推送呢。

1. 总体结论

结论：完全可行，且不必从零写引擎。中文输入法的核心（拼音引擎 + 词库）已有成熟开源方案RIME/librime（BSD-3-Clause，4.6k stars，2026-06 刚发 1.17.0，维护活跃），"自研输入法"的工作量集中在前端（UI/系统集成）和隐私架构上，引擎层直接复用。
推荐架构：librime 引擎 + 自研前端。Windows 端基于Win32 低级键盘钩子 + 自研候选窗（Tauri 或原生 C++/Rust），macOS 端基于InputMethodKit + 自研候选窗，Linux 端可先借用 fcitx5 框架验证引擎再决定是否自研。
为什么不直接 fork 小狼毫（weasel）：weasel 是 GPL-3.0，自用没问题，但要发布产品就必须开源你的全部修改且衍生作品同样 GPL；如果想保留闭源/自由分发的权利，前端必须自研（引擎 librime 是 BSD-3，无此限制）。自用派 → fork weasel 最省事；要分发派 → 自研前端 + librime。
许可证风险表见 §2，全部组件已多源核查（2026-09-20 GitHub API 实测）。

2. 开源组件许可证核查（2026-09-20，GitHub API 实测）

组件	角色	许可证	版本/状态（实测）	风险
librime	核心引擎（C++17）	BSD-3-Clause	1.17.0（2026-06-06），master 2026-09-18 仍在提交	无。可闭源分发、可商用
weasel 小狼毫	Windows 前端参考实现	GPL-3.0	8.0k stars，活跃	仅参考不 fork，无风险；fork 发布则全量 GPL 传染
squirrel 鼠须管	macOS 前端参考实现	GPL-3.0	6.4k stars，活跃	同上
fcitx5	Linux 输入法框架（参考/备选宿主）	LGPL-3.0（COPYING.LGPL，404 路径已换主仓库）	2.6k stars，2026-09-20 当天有提交	低。LGPL 允许动态链接闭源使用
OpenCC	简繁转换	Apache-2.0	BYVoid/OpenCC，9.99k stars，2026-09-19 活跃	无
rime-ice 中州韵	主流拼音方案（schema + 词库）	GPL-3.0	iDvel/rime-ice，19.4k stars，活跃	中。schema 数据 GPL，分发时须随附或声明来源；纯自用无影响
rime-luna-pinyin 朙月拼音	另一套主流拼音方案	LGPL-3.0	活跃	低
rime-essay	公共词库/语言模型	LGPL-3.0	活跃	低
librime-lua / librime-octagram / librime-predict	脚本扩展 / ngram 语言模型 / 预测下一词	BSD-3-Clause（随 librime 系）	活跃	无
marisa-trie / leveldb / yaml-cpp	librime 底层依赖	BSDL / BSD / MIT	—	无

关键判断：

引擎链路（librime + OpenCC + 依赖）全部宽松许可证，商用/闭源分发无障碍。
GPL 只出现在"方案数据"（rime-ice 词库）和"前端参考实现"（weasel/squirrel）。两条合规路径：
1. 自用：随便用，GPL 不约束你；
2. 分发：a) 自研前端（GPL 不传染）+ 词库随包附源码声明 GPL 来源（或换 LGPL 的朙月方案）；b) 整个产品直接走 GPL-3.0 开源分发（最干净，且符合"隐私开源输入法"的定位，社区接受度最高）。
- 建议选 2b：这类产品（参考开源输入法生态惯例）开源本身就是卖点，和"无遥测"形成互证。

3. 候选引擎横向对比

引擎	语言	成熟度	中文能力	结论
librime (RIME)	C++17	10 年+，iOS/Android/桌面/Vim/Emacs 全平台前端生态	拼音/五笔/双拼/自定义 DSL，词库热更新，用户词库自动学习	选定。中文输入领域唯一全功能开源引擎
fcitx5 自带引擎	C++	活跃	有拼音引擎但词库/学习机制弱于 RIME	不做引擎，Linux 端可当宿主参考
Rust 系（karukan 等）	Rust	早期（百星级，日文/越南语为主）	中文拼音词库与方案体系不成熟	观望，不用于生产
自研引擎	—	—	需从零做拼音 trie + 用户词库 + 语言模型，工作量 ≥6 个月且效果难追 RIME	否决

4. 技术实现方案

4.1 架构总览

┌─────────────────────────────────────────────────────────┐ │ 前端层（自研，每平台一套） │ │ Windows: Rust/Tauri 或 C++(Win32) │ │ · 全局低级键盘钩子 (WH_KEYBOARD_LL) │ │ · 候选窗（无边框置顶窗, DWM 阴影, 深色模式） │ │ · 托盘图标 / 热键 (Shift切中英文, Ctrl+Space启停) │ │ macOS: Swift + InputMethodKit (IMKServer/IMKCandidates) │ │ Linux: 第一阶段直接出 fcitx5 配置验证，二期评估自研 portal 前端 │ ├─────────────────────────────────────────────────────────┤ │ 引擎层（复用，进程内动态库 or 独立进程 IPC） │ │ librime 1.17 (BSD-3) │ │ · 拼音方案 (rime-ice 或自维护 schema) │ │ · OpenCC 简繁 (Apache-2.0) │ │ · 用户词库 (leveldb, 本地学习) │ │ · librime-lua 扩展点 (可选: 本地LLM增强, 见§4.4) │ ├─────────────────────────────────────────────────────────┤ │ 数据层（100% 本地，零网络） │ │ ~/.{name}/ │ │ userdb/ 用户词库 (leveldb) │ │ schema/ 方案与词库 (yaml + bin) │ │ logs/ 仅本地日志, 无上传 │ └─────────────────────────────────────────────────────────┘ 网络面: 无。唯一的网络行为 = 用户手动点"检查更新"(可选, 可编译期禁用)

4.2 核心模块设计

① 键盘钩子与输入态机（Windows 前端，最难的部分）

WH_KEYBOARD_LL低级钩子拦截按键 → 状态机：IDLE → COMPOSING → SELECTING；
组合中按键送给 librimeProcessKey(keycode, control_code, commit)；
中文上屏走SendInput（模拟字符输入，兼容几乎所有应用；IME 框架级注入则需注册真 IME，复杂度高一档，见 §4.3 选型）；
必须处理的经典坑：钩子回调超 300ms 会被系统强制移除（回调内只做状态切换，重活丢引擎线程）、游戏/管理员窗口 UAC 提权差异（钩子要按 integrity level 注入）、Ctrl/Ctrl+Alt+Del 必须透传。

② 候选窗 UI

无边框置顶、跟随光标定位（Windows:NtGdiQueryDisplayConfig或简单取光标+屏幕防越界）、数字键 1-9/0 选择、鼠标点击、翻页[ ]；
候选条内容来自 librimeGetContext（candidate list + menu + highligh index）；
UI 技术二选一：
- Tauri（Rust + WebView2）：UI 开发快（HTML/CSS，可直接复用 Vue/TS 技能栈），首帧渲染 ~100ms 需做预热窗口解决；
- 原生（Win32 Direct2D 或 Rust winit）：延迟最低（<10ms）、无 WebView 内存开销，但 UI 开发量大 3-5 倍。
- 建议：v1 用 Tauri 快速出可用品，用户输入延迟敏感反馈多再换原生渲染。

③ 引擎集成与线程模型

librime 单实例非线程安全：独立引擎线程 + 消息队列，钩子线程只做入队；
词库/用户词库写入走 librime 内置 sync 机制，避免与 UI 读竞争；
首次部署需离线跑一次rime_deployer等价流程把 yaml schema 编译为 bin（可用rime-plugin的 deploy 逻辑或自己调Schema::Deploy）。

④ 隐私架构（产品的灵魂，也是和所有商业输入法的差异点）

零网络代码：编译产物里不存在任何 HTTP 客户端依赖；用 CI 的静态扫描（cargo-audit/ 依赖清单审计）+ 运行时strace/ltrace验证无 socket 调用，作为发布前的标准检查并公开报告；
用户词库：本地 leveldb，可一键导出/删除；
可选端到端加密云备份（差异化功能，默认关）：词库同步走用户自备的 S3/自建服务器，加密密钥只在本地（AGE/SOPS 标准），服务器只存密文；
可审计性：全开源 + 签名发布（Windows Authenticode / macOS notarization），附"无遥测"声明页，列出全部第三方依赖及其许可证（§2 表格直接放官网）。

4.3 两种系统集成路线对比（Windows）

路线 A：低级钩子 + SendInput（伪输入法）	路线 B：注册真 IME（TSF 文本服务框架）
开发量	中（1-2 个月出 v1）	大（TSF COM 组件 + 注册表 + 语言栏，2-4 个月）
兼容性	绝大多数应用 OK；部分游戏/反作弊/全屏独占、UAC 提权窗口可能不识别	系统级，100% 应用识别，语言栏/任务栏状态正常
候选窗控制	完全自主	完全自主（自绘窗）
参考实现	weasel 实际走的近似路线（weasel 用的是 IM 框架注入，介于两者间）	微软 TSF 文档 + 各开源 IME 实现
建议	v1 走 A，快速验证	桌面用户反馈"某些软件不出候选"后升级 B

4.4 可选增强（第二期，差异化方向）

本地 LLM 词库增强：librime-lua 扩展点挂本地小模型（内网已有 2080Ti 跑 Qwen 的基建），做长句/领域词预测——模型只读本句输入 + 本地词库，无网络，隐私卖点再加固；
用户自定义词库导入：Excel/CSV 批量导入（公司场景：内部系统名、项目代号自动出词）；
云词库订阅（严格可选）：默认关闭，用户显式开启且只拉取匿名词频表，不含任何输入内容。

4.5 里程碑与工作量估算（按 1 名全栈开发 + AI 辅助）

阶段	内容	周期	验收标准
M0	环境：Windows 装 weasel 用 librime 1.17，把 rime-ice 调到自己满意的出词效果	1 周	日常打字 1 周无不适（这步决定引擎选型成败，必须先做）
M1	引擎进程化：librime 打包为独立服务进程 + gRPC/CapnProto IPC（复用 librime-proto 插件），Python/TS 客户端调通	2 周	命令行里完整走通"输入→候选→选择→上屏"
M2	Windows v1：钩子 + Tauri 候选窗 + SendInput 上屏 + 托盘	4-6 周	日常主力使用 1 个月，崩溃率 <1 次/周，打字延迟主观无感
M3	隐私验证 + 发布：CI 网络审计、签名打包（WiX/MSIX）、更新机制、官网依赖声明	2 周	公开可复现的"零网络"验证报告
M4	macOS 版（InputMethodKit + Swift 候选窗）；Linux 出 fcitx5 配置方案	4 周	双平台自用稳定
M5（可选）	TSF 真输入法升级 / 本地 LLM 增强 / 加密云备份	视反馈	—

总预估：M0-M3（Windows 可发布版）约2.5-3 个月；加 macOS 约 4 个月。有 AI 辅助编码 + 本方案文档，主要风险集中在 M2 的钩子兼容性和 Tauri 候选窗延迟。

5. 风险与缓解

风险	等级	缓解
Tauri 候选窗首帧/延迟不达标（WebView 冷启动）	高	预热隐藏窗口常驻；M2 设硬性指标（按键到候选显示 P95 < 80ms），不达标切 winit 原生渲染
钩子方案在部分软件失效（游戏/UAC）	中	v1 文档明示已知限制；M5 升级 TSF
rime-ice 词库 GPL 传染担忧（分发场景）	低	整包走 GPL 开源（推荐）或换 LGPL 朙月方案 + 自维护词库
librime C++ 编译链繁琐（boost/marisa/leveldb 依赖）	低	用 vcpkg 或预编译静态库；社区已有各平台预编译（weasel 安装包内即可提取验证）
单人维护长尾平台适配	中	聚焦 Windows 自用，macOS/Linux 降级为"给官方 rime 前端打配置"而非自研前端