简介livla 是一套面向 Lojban 语言学习者和开发者的工具组合整合了解析器、词典查询、搜索界面及 IRC 机器人等模块既适合人工语言爱好者搭建练习环境也能为自然语言处理方向的二次开发提供参考。压缩包共 2000 个文件约 44.38MB内容以 mp3 音频、C/H 源码、JavaScript、JSON 与 HTML 为主音频用于发音和例句参考C/H 与 JS 构成解析和前端逻辑JSON 存放词典与配置数据另有 Perl 脚本和 Dockerfile 方便部署扩展。目前已有 167 人学习下载。这套资源包含 jbofihe、vlatai 等解析与词表查询工具以及对应网页界面和语音数据配合 Docker 配置与 IRC 机器人接入说明能在本地快速跑起完整的 Lojban 工具链。对于想要深入理解 Lojban 文法、尝试自建词典或扩展语言工具的人具有直接参考价值。1. 先回答一个真问题Lojban 工具链到底缺什么聊到 livla 这个 Lojban 工具组合很多第一次接触的人会问一门人工语言拿通用 parser 去解析不就行了为什么要单独做一套工具链答案是差在整条链路上。Lojban 词典查询、语法解析、搜索界面这三件事每一件都有和自然语言工具完全不同的规则词形变化会吃词根、句法歧义被形式文法锁死、HTML 前端要同时处理 UTF-8 特殊字符和长文本解析。livla 的定位不是「又一个 Lojban 词典」而是把 lojban parser、search-interface、dictionary-software 三个模块拧在一起让「查词 → 查语法 → 看例句」这一条流程能顺畅跑通。这篇文章就从这三个模块逐个拆开讲讲清楚它解决什么、怎么接入、坑在哪。2. Lojban 语法解析为什么通用 NLP parser 接不住这门语言2.1 形式文法与 PEGLojban 解析的底层规则先明确一个概念Lojban 的语法不是「概率模型猜出来的」而是用形式文法写死的。官方文法基于 PEGParsing Expression Grammar也就是说任何一个合法句子都能被唯一地归约成一棵语法树。这个特性和自然语言处理里的统计 parser 有本质区别——后者需要大规模语料训练前者只需要一套规则表。所以 livla 里的 parser 模块本质上是一个 PEG 解析器的实例化文法文件描述了从顶层结构bridi即命题到最小词类cmavo即结构词的完整规则。常见的结构是bridi - sumti? selbri sumti* selbri - tanru? gismu / lujvo sumti - le_sumti / la_sumti / ko_sumti / ...这段文法片段说明三件事句子以谓词selbri为核心前后挂论元sumti谓词可以由单个词根gismu构成也可以是复合词lujvo论元的最常见形式是「le 词根」这种限定结构。PEG 的特点是带优先级的选择/左侧优先所以歧义是被文法规则本身消除的而不是靠后续消歧。用的时候要注意Lojban 文法是「可选词序」的sumti 可以出现在 selbri 前面或后面所以 parser 不能像英语 parser 那样按固定语序分析。很多通用 parser 接不住 Lojban就是因为它们的句法假设是 SVO 或 SOV 固定的。2.2 livla parser 的调用方式与参数语义livla 的 parser 做了封装对外暴露的接口很干净。我通常在浏览器端这么调const parser new LivlaParser({ grammarSource: ./grammar/lojban-full-grammar.cfg, stage: strict, // strict | relaxed maxWords: 200, // 单句最长词数 collectErrors: true // 收集所有错误而非遇到第一个就停 }); const sentence mi cliva le zdani; const result parser.parse(sentence); if (result.ok) { console.log(result.tree); // AST 对象 console.log(result.rulePath); // 命中的规则路径数组 } else { console.log(result.errors); // 错误数组 }grammarSource指向打包好的完整文法文件。stage参数决定解析严格度strict模式下任何未命中规则的词都会直接报错relaxed模式会把未识别词当作借词fuivla处理适合处理人名、地名这类外来词。maxWords是防爆参数Lojban 句子可以无限嵌套不限制的话一个超长句子可能让浏览器卡死。返回的result.tree是标准 AST每个节点带rule和text两个字段rulePath记录了从顶层到叶子经过的规则序列这个字段在排查「为什么这句解析失败」时非常有用。2.3 解析结果怎么读、失败时看什么拿到 AST 之后最直接的做法是写一个遍历器把层级结构可视化function dumpTree(node, depth 0) { const indent .repeat(depth); console.log(${indent}${node.rule}: ${node.text}); if (node.children) { node.children.forEach(child dumpTree(child, depth 1)); } }输出长这样bridi: mi cliva le zdani sumti: mi cmavo: mi selbri: cliva gismu: cliva sumti: le zdani le_sumti: le zdani cmavo: le selbri: zdani gismu: zdani这个输出能直接告诉你两件事词被归到了哪个类别是 cmavo 还是 gismu句子结构是否符合你的预期。如果「le zdani」被解析成「le」「zdani」而不是一个整体说明某个词的词性判定有问题。解析失败时优先看errors[0].offset——错误位置是指向词之间还是词内部。指向词内部基本可以断定是形态切分问题指向两个词之间则是文法规则没覆盖到某种组合。这两种情况和自然语言 parser 的「缺词」是两码事排错思路完全不同。3. 词典层与搜索界面从词形反查词根的 HTML 实战3.1 Lojban 词典的数据结构词形到词根不是一对一Lojban 词典和普通双语词典最大的差异在词项组织方式。词典真正的词条是 gismu根词约 1300 个但用户在搜索框里输入的往往是经过形态变化的形式——加了时态、加了否定、或者拼进了复合词。所以词典软件必须做一层「词形还原stemming」否则「cliva」查得到、「clivavoi」这种带后缀的形式就查不到。livla 里 dictionary-software 模块的数据结构大致是这样的字段说明示例word词形可带 rafsi 变体cliva / cliv-stem对应的 gismu 原型clivatype词类gismu / cmavo / lujvo / fuivladefinition英文释义leave, departrafsi词根缩写列表cli / livexample例句与译文mi cliva le zdani这个结构决定了搜索逻辑不仅要做「精确匹配」还要做「词形还原匹配」和「rafsi 片段匹配」。用户在搜索框输入「cliv」系统要能联想到 cliva、clivavoi 等词项。3.2 搜索接口怎么设计参数livla 的搜索接口我建议按三个查询模式来处理参数化之后前端调用很清爽async function lookup(query, mode) { const params new URLSearchParams({ q: query, lang: en, limit: 20 }); if (mode) params.set(mode, mode); const resp await fetch(/api/dict?${params.toString()}); return resp.json(); }接口参数有三个q是查询词形mode有三个取值——exact精确匹配、stem词形还原匹配、fragmentrafsi 片段匹配limit控制返回条数。前端输入框默认走stem模式这样「clivavoi」能还原到 cliva语义最合理。响应体是一个数组每个元素包含词条字段还带一个matchedBy字段标记本次是通过哪种模式命中的。这个字段前端通常不用展示但调试时极有用——它能告诉你用户搜的词和库里的词之间到底是通过什么规则搭上的。3.3 HTML 搜索框的交互层防抖、候选下沉、释义卡片前端界面是标准的单页结构一个输入框、一个候选列表、一个释义面板。核心交互逻辑用一个带防抖的输入监听实现let debounceTimer; searchInput.addEventListener(input, (e) { clearTimeout(debounceTimer); const q e.target.value.trim(); // 输入为空或长度不足时不发请求 if (q.length 2) { renderCandidates([]); return; } // 300ms 防抖避免每个键都打一次接口 debounceTimer setTimeout(async () { const data await lookup(q, stem); renderCandidates(data.slice(0, 8)); }, 300); });防抖的 300ms 是针对本机词典查询场景测出来的低于这个值快速输入时会频繁打断请求高于这个值搜索框会显得反应迟钝。候选列表只渲染前 8 条超出部分在用户继续输入或点击「更多」时才展开。点击候选词后释义面板拉全文async function renderDefinition(word) { const entry await lookup(word, exact); const defPanel document.getElementById(definition-panel); defPanel.innerHTML h3${entry[0].stem}/h3 p classpos${entry[0].type}/p p${entry[0].definition}/p p classexample${entry[0].example}/p ; }注意释义面板里的词头显示的是entry[0].stem而不是用户输入的原词这是有意为之——用户从候选列表点进来的词是还原后的词根展示词根能避免「同一个词有两个拼写」的困惑。4. 把 parser 和词典串成完整工具链一个可复现的 HTML 前端方案4.1 前端直连 parser把语法树变成释义入口很多 Lojban 工具把 parser 放后端前端只发请求拿结果。livla 的这套组合推荐把 parser 放前端原因是 Lojban 文法规则表是静态的体积不大加载一次之后本地就能跑省掉一轮网络延迟。核心做法是页面加载时初始化 parser用户点选句子里的任意一个词时用这个词在 AST 里的节点信息去词典层反查// 页面初始化 const parser new LivlaParser({ grammarSource: ./grammar/lojban-full-grammar.cfg, stage: strict }); // 用户点击句子中的某个词 sentenceText.addEventListener(click, (event) { const word event.target.dataset.word; const rule event.target.dataset.rule; // 按词形词性联合查词典减少歧义 const entries lookupByWordAndRule(word, rule); renderDefinitionPanel(entries[0]); });这里的关键是把 AST 节点的rule字段绑定到 DOM 的>const parseCache new Map(); function parseWithCache(sentence) { if (parseCache.has(sentence)) { return parseCache.get(sentence); } const ast parser.parse(sentence); parseCache.set(sentence, ast); return ast; }词典查询也同理按「词形 mode rule」三元组做缓存键。这套组合在实际使用中能把重复点击的响应时间从 200ms 压到 20ms 以内优化效果非常直观。4.3 离线降级与静态词典快照前端直连 parser 的一个隐藏好处是天然支持离线使用。livla 资源包里通常自带一份词典快照JSON 格式加载一次后存进 IndexedDB后续查询优先走本地。async function lookupWithFallback(q, mode) { // 优先本地 const local await lookupLocal(q, mode); if (local.length 0) return local; // 本地没有远程拉 const remote await lookupRemote(q, mode); cacheToLocal(remote); // 写回本地 return remote; }这个降级策略要考虑一个边界本地快照的词条数是固定的新造词lujvo 复合词永远查不到。补救做法是查不到时把输入丢给 parser 做一次形态还原用还原后的词根再查一次。这属于工具链的自然延伸——parser 和词典本来就是一套数据流里的两个节点。5. 避坑清单Lojban 工具落地中的实测踩坑记录5.1 形态分词把 cmavo 链切错了现象句子「mi pu klama le zdani」我过去去过那个房子parser 报错在「pu」附近或者把「pu」和后面的词错误地合成一个整体。原因Lojban 的 cmavo结构词是开放的音节组合一个词可能同时是「pu」这个时态标记的一部分。形态分词器在词边界判断上用了「最短路匹配」导致相邻 cmavo 被合并成一个不存在的词。解决把分词器的策略改成「最长匹配优先」——先试整个字符串能否命中已有词表不行再切分。另外在LivlaParser初始化时把stage: strict临时改成relaxed能快速验证是否是分词问题如果 relaxed 下解析通过基本可以断定是词表匹配逻辑的问题。5.2 词典里查「clivavoi」查不到现象用户输入带后缀的派生词形词典返回空结果。原因词典只建了 gismu 词条没有做词形还原索引。任何带 rafsi 变体或形态后缀的词精确匹配和前缀匹配都命中不了。解决搜索接口默认模式改成stem并在词典构建阶段预先对每个词条生成「词形变体表」把 cliv-, cli, liv 这些 rafsi 全部挂到 cliva 词条下。这样「clivavoi」先被切成 cliva voi再按 cliva 命中。5.3 HTML 搜索框里输入特殊字符导致请求失效现象输入「mio」第一人称复数含撇号或「.eu」这类词请求返回 400。原因Lojban 里撇号是合法字母但 HTML 表单或 URL 编码没对它做转义服务端解析失败点号.在 URL 里也可能被路由层吃掉。解决前端所有查询请求统一走URLSearchParams它会自动处理编码不要手拼 query string。服务端做一层防御性解码把%27还原成撇号后传给词典模块。5.4 长句解析直接卡死浏览器现象一个超过 300 词的 Lojban 句子点击解析后页面无响应控制台报 JS 堆栈溢出。原因PEG 解析器本质是递归下降嵌套的 sumti 结构会触发深层递归。默认的maxWords没设限句子越长调用栈越深最终爆栈。解决初始化时把maxWords明确设到一个合理值200 词足够覆盖绝大多数语料场景。另外在解析调用外层包一个try/catch捕获 RangeError 时提示用户「句子过长」而不是让页面白屏try { const result parser.parse(sentence); renderTree(result.tree); } catch (err) { if (err instanceof RangeError) { alert(句子过长或嵌套过深请拆分后再试); } else { throw err; } }5.5 同一个 rafsi 挂了多个 gismu取了第一个导致释义错误现象查「bli」返回的结果不是预期的词根而是另一个共享同一 rafsi 的词根。原因Lojban 的 rafsi 不是一一对应的多个 gismu 可能共用同一个缩写。词典接口按 rafsi 片段匹配时默认取第一个命中项没有做权重处理。解决在词典数据结构里给rafsi字段增加「关联词根列表」搜索时把所有候选项按词频或按是否出现在当前句子的 AST 中排序而不是按字母序。更稳妥的做法是返回候选数组让用户自己选前端展示「你也可能是要找A / B / C」。6. 进阶用法给工具链做回归验证与批量解析工具链能跑通只是第一步真正要长期维护得把「怎么验证它没坏」这件事也做起来。livla 这套组合的验证方式很朴素准备一批「句子 → 期望 AST 结构」的黄金测试集每次改完文法或词典字段就跑一遍全量回归。我一般这么组织测试const testCases [ { sentence: mi cliva le zdani, expectRule: bridi, expectSatisfy: (ast) ast.children[1].rule selbri }, { sentence: le nanla cu pendo mi, expectRule: bridi, expectSatisfy: (ast) ast.children[0].rule le_sumti } ]; testCases.forEach(({ sentence, expectRule, expectSatisfy }, index) { const result parser.parse(sentence); const passed result.ok result.tree.rule expectRule expectSatisfy(result.tree); console.log(case ${index}: ${passed ? PASS : FAIL}, sentence); });这类回归的价值在词典更新时特别明显——你加了一个新词条可能不小心把某个旧词条的形态还原规则顶掉了跑一遍测试集能立刻看到哪个句子的 AST 结构变了样。另一个值得做的进阶点是批量解析覆盖率统计拿一篇 Lojban 文本逐句解析统计「完全解析成功 / 部分失败 / 完全失败」的句子比例低于 85% 时基本可以断定文法文件有缺失或分词器有 bug。我现在的习惯是每次改完词典索引都强制跑一遍这组测试已经从「查完一个词发现不对再回头改」变成了「改完立刻知道哪坏了」。这套 livla 资源包里的 parser 和词典数据按照上面这套流程搭起来日常查词和验证句子结构都够用了希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/18 12:55:22 · 阅读 1.2k Lojban工具链livla实战：从PEG语法解析到词典搜索
简介livla 是一套面向 Lojban 语言学习者和开发者的工具组合整合了解析器、词典查询、搜索界面及 IRC 机器人等模块既适合人工语言爱好者搭建练习环境也能为自然语言处理方向的二次开发提供参考。压缩包共 2000 个文件约 44.38MB内容以 mp3 音频、C/H 源码、JavaScript、JSON 与 HTML 为主音频用于发音和例句参考C/H 与 JS 构成解析和前端逻辑JSON 存放词典与配置数据另有 Perl 脚本和 Dockerfile 方便部署扩展。目前已有 167 人学习下载。这套资源包含 jbofihe、vlatai 等解析与词表查询工具以及对应网页界面和语音数据配合 Docker 配置与 IRC 机器人接入说明能在本地快速跑起完整的 Lojban 工具链。对于想要深入理解 Lojban 文法、尝试自建词典或扩展语言工具的人具有直接参考价值。1. 先回答一个真问题Lojban 工具链到底缺什么聊到 livla 这个 Lojban 工具组合很多第一次接触的人会问一门人工语言拿通用 parser 去解析不就行了为什么要单独做一套工具链答案是差在整条链路上。Lojban 词典查询、语法解析、搜索界面这三件事每一件都有和自然语言工具完全不同的规则词形变化会吃词根、句法歧义被形式文法锁死、HTML 前端要同时处理 UTF-8 特殊字符和长文本解析。livla 的定位不是「又一个 Lojban 词典」而是把 lojban parser、search-interface、dictionary-software 三个模块拧在一起让「查词 → 查语法 → 看例句」这一条流程能顺畅跑通。这篇文章就从这三个模块逐个拆开讲讲清楚它解决什么、怎么接入、坑在哪。2. Lojban 语法解析为什么通用 NLP parser 接不住这门语言2.1 形式文法与 PEGLojban 解析的底层规则先明确一个概念Lojban 的语法不是「概率模型猜出来的」而是用形式文法写死的。官方文法基于 PEGParsing Expression Grammar也就是说任何一个合法句子都能被唯一地归约成一棵语法树。这个特性和自然语言处理里的统计 parser 有本质区别——后者需要大规模语料训练前者只需要一套规则表。所以 livla 里的 parser 模块本质上是一个 PEG 解析器的实例化文法文件描述了从顶层结构bridi即命题到最小词类cmavo即结构词的完整规则。常见的结构是bridi - sumti? selbri sumti* selbri - tanru? gismu / lujvo sumti - le_sumti / la_sumti / ko_sumti / ...这段文法片段说明三件事句子以谓词selbri为核心前后挂论元sumti谓词可以由单个词根gismu构成也可以是复合词lujvo论元的最常见形式是「le 词根」这种限定结构。PEG 的特点是带优先级的选择/左侧优先所以歧义是被文法规则本身消除的而不是靠后续消歧。用的时候要注意Lojban 文法是「可选词序」的sumti 可以出现在 selbri 前面或后面所以 parser 不能像英语 parser 那样按固定语序分析。很多通用 parser 接不住 Lojban就是因为它们的句法假设是 SVO 或 SOV 固定的。2.2 livla parser 的调用方式与参数语义livla 的 parser 做了封装对外暴露的接口很干净。我通常在浏览器端这么调const parser new LivlaParser({ grammarSource: ./grammar/lojban-full-grammar.cfg, stage: strict, // strict | relaxed maxWords: 200, // 单句最长词数 collectErrors: true // 收集所有错误而非遇到第一个就停 }); const sentence mi cliva le zdani; const result parser.parse(sentence); if (result.ok) { console.log(result.tree); // AST 对象 console.log(result.rulePath); // 命中的规则路径数组 } else { console.log(result.errors); // 错误数组 }grammarSource指向打包好的完整文法文件。stage参数决定解析严格度strict模式下任何未命中规则的词都会直接报错relaxed模式会把未识别词当作借词fuivla处理适合处理人名、地名这类外来词。maxWords是防爆参数Lojban 句子可以无限嵌套不限制的话一个超长句子可能让浏览器卡死。返回的result.tree是标准 AST每个节点带rule和text两个字段rulePath记录了从顶层到叶子经过的规则序列这个字段在排查「为什么这句解析失败」时非常有用。2.3 解析结果怎么读、失败时看什么拿到 AST 之后最直接的做法是写一个遍历器把层级结构可视化function dumpTree(node, depth 0) { const indent .repeat(depth); console.log(${indent}${node.rule}: ${node.text}); if (node.children) { node.children.forEach(child dumpTree(child, depth 1)); } }输出长这样bridi: mi cliva le zdani sumti: mi cmavo: mi selbri: cliva gismu: cliva sumti: le zdani le_sumti: le zdani cmavo: le selbri: zdani gismu: zdani这个输出能直接告诉你两件事词被归到了哪个类别是 cmavo 还是 gismu句子结构是否符合你的预期。如果「le zdani」被解析成「le」「zdani」而不是一个整体说明某个词的词性判定有问题。解析失败时优先看errors[0].offset——错误位置是指向词之间还是词内部。指向词内部基本可以断定是形态切分问题指向两个词之间则是文法规则没覆盖到某种组合。这两种情况和自然语言 parser 的「缺词」是两码事排错思路完全不同。3. 词典层与搜索界面从词形反查词根的 HTML 实战3.1 Lojban 词典的数据结构词形到词根不是一对一Lojban 词典和普通双语词典最大的差异在词项组织方式。词典真正的词条是 gismu根词约 1300 个但用户在搜索框里输入的往往是经过形态变化的形式——加了时态、加了否定、或者拼进了复合词。所以词典软件必须做一层「词形还原stemming」否则「cliva」查得到、「clivavoi」这种带后缀的形式就查不到。livla 里 dictionary-software 模块的数据结构大致是这样的字段说明示例word词形可带 rafsi 变体cliva / cliv-stem对应的 gismu 原型clivatype词类gismu / cmavo / lujvo / fuivladefinition英文释义leave, departrafsi词根缩写列表cli / livexample例句与译文mi cliva le zdani这个结构决定了搜索逻辑不仅要做「精确匹配」还要做「词形还原匹配」和「rafsi 片段匹配」。用户在搜索框输入「cliv」系统要能联想到 cliva、clivavoi 等词项。3.2 搜索接口怎么设计参数livla 的搜索接口我建议按三个查询模式来处理参数化之后前端调用很清爽async function lookup(query, mode) { const params new URLSearchParams({ q: query, lang: en, limit: 20 }); if (mode) params.set(mode, mode); const resp await fetch(/api/dict?${params.toString()}); return resp.json(); }接口参数有三个q是查询词形mode有三个取值——exact精确匹配、stem词形还原匹配、fragmentrafsi 片段匹配limit控制返回条数。前端输入框默认走stem模式这样「clivavoi」能还原到 cliva语义最合理。响应体是一个数组每个元素包含词条字段还带一个matchedBy字段标记本次是通过哪种模式命中的。这个字段前端通常不用展示但调试时极有用——它能告诉你用户搜的词和库里的词之间到底是通过什么规则搭上的。3.3 HTML 搜索框的交互层防抖、候选下沉、释义卡片前端界面是标准的单页结构一个输入框、一个候选列表、一个释义面板。核心交互逻辑用一个带防抖的输入监听实现let debounceTimer; searchInput.addEventListener(input, (e) { clearTimeout(debounceTimer); const q e.target.value.trim(); // 输入为空或长度不足时不发请求 if (q.length 2) { renderCandidates([]); return; } // 300ms 防抖避免每个键都打一次接口 debounceTimer setTimeout(async () { const data await lookup(q, stem); renderCandidates(data.slice(0, 8)); }, 300); });防抖的 300ms 是针对本机词典查询场景测出来的低于这个值快速输入时会频繁打断请求高于这个值搜索框会显得反应迟钝。候选列表只渲染前 8 条超出部分在用户继续输入或点击「更多」时才展开。点击候选词后释义面板拉全文async function renderDefinition(word) { const entry await lookup(word, exact); const defPanel document.getElementById(definition-panel); defPanel.innerHTML h3${entry[0].stem}/h3 p classpos${entry[0].type}/p p${entry[0].definition}/p p classexample${entry[0].example}/p ; }注意释义面板里的词头显示的是entry[0].stem而不是用户输入的原词这是有意为之——用户从候选列表点进来的词是还原后的词根展示词根能避免「同一个词有两个拼写」的困惑。4. 把 parser 和词典串成完整工具链一个可复现的 HTML 前端方案4.1 前端直连 parser把语法树变成释义入口很多 Lojban 工具把 parser 放后端前端只发请求拿结果。livla 的这套组合推荐把 parser 放前端原因是 Lojban 文法规则表是静态的体积不大加载一次之后本地就能跑省掉一轮网络延迟。核心做法是页面加载时初始化 parser用户点选句子里的任意一个词时用这个词在 AST 里的节点信息去词典层反查// 页面初始化 const parser new LivlaParser({ grammarSource: ./grammar/lojban-full-grammar.cfg, stage: strict }); // 用户点击句子中的某个词 sentenceText.addEventListener(click, (event) { const word event.target.dataset.word; const rule event.target.dataset.rule; // 按词形词性联合查词典减少歧义 const entries lookupByWordAndRule(word, rule); renderDefinitionPanel(entries[0]); });这里的关键是把 AST 节点的rule字段绑定到 DOM 的>const parseCache new Map(); function parseWithCache(sentence) { if (parseCache.has(sentence)) { return parseCache.get(sentence); } const ast parser.parse(sentence); parseCache.set(sentence, ast); return ast; }词典查询也同理按「词形 mode rule」三元组做缓存键。这套组合在实际使用中能把重复点击的响应时间从 200ms 压到 20ms 以内优化效果非常直观。4.3 离线降级与静态词典快照前端直连 parser 的一个隐藏好处是天然支持离线使用。livla 资源包里通常自带一份词典快照JSON 格式加载一次后存进 IndexedDB后续查询优先走本地。async function lookupWithFallback(q, mode) { // 优先本地 const local await lookupLocal(q, mode); if (local.length 0) return local; // 本地没有远程拉 const remote await lookupRemote(q, mode); cacheToLocal(remote); // 写回本地 return remote; }这个降级策略要考虑一个边界本地快照的词条数是固定的新造词lujvo 复合词永远查不到。补救做法是查不到时把输入丢给 parser 做一次形态还原用还原后的词根再查一次。这属于工具链的自然延伸——parser 和词典本来就是一套数据流里的两个节点。5. 避坑清单Lojban 工具落地中的实测踩坑记录5.1 形态分词把 cmavo 链切错了现象句子「mi pu klama le zdani」我过去去过那个房子parser 报错在「pu」附近或者把「pu」和后面的词错误地合成一个整体。原因Lojban 的 cmavo结构词是开放的音节组合一个词可能同时是「pu」这个时态标记的一部分。形态分词器在词边界判断上用了「最短路匹配」导致相邻 cmavo 被合并成一个不存在的词。解决把分词器的策略改成「最长匹配优先」——先试整个字符串能否命中已有词表不行再切分。另外在LivlaParser初始化时把stage: strict临时改成relaxed能快速验证是否是分词问题如果 relaxed 下解析通过基本可以断定是词表匹配逻辑的问题。5.2 词典里查「clivavoi」查不到现象用户输入带后缀的派生词形词典返回空结果。原因词典只建了 gismu 词条没有做词形还原索引。任何带 rafsi 变体或形态后缀的词精确匹配和前缀匹配都命中不了。解决搜索接口默认模式改成stem并在词典构建阶段预先对每个词条生成「词形变体表」把 cliv-, cli, liv 这些 rafsi 全部挂到 cliva 词条下。这样「clivavoi」先被切成 cliva voi再按 cliva 命中。5.3 HTML 搜索框里输入特殊字符导致请求失效现象输入「mio」第一人称复数含撇号或「.eu」这类词请求返回 400。原因Lojban 里撇号是合法字母但 HTML 表单或 URL 编码没对它做转义服务端解析失败点号.在 URL 里也可能被路由层吃掉。解决前端所有查询请求统一走URLSearchParams它会自动处理编码不要手拼 query string。服务端做一层防御性解码把%27还原成撇号后传给词典模块。5.4 长句解析直接卡死浏览器现象一个超过 300 词的 Lojban 句子点击解析后页面无响应控制台报 JS 堆栈溢出。原因PEG 解析器本质是递归下降嵌套的 sumti 结构会触发深层递归。默认的maxWords没设限句子越长调用栈越深最终爆栈。解决初始化时把maxWords明确设到一个合理值200 词足够覆盖绝大多数语料场景。另外在解析调用外层包一个try/catch捕获 RangeError 时提示用户「句子过长」而不是让页面白屏try { const result parser.parse(sentence); renderTree(result.tree); } catch (err) { if (err instanceof RangeError) { alert(句子过长或嵌套过深请拆分后再试); } else { throw err; } }5.5 同一个 rafsi 挂了多个 gismu取了第一个导致释义错误现象查「bli」返回的结果不是预期的词根而是另一个共享同一 rafsi 的词根。原因Lojban 的 rafsi 不是一一对应的多个 gismu 可能共用同一个缩写。词典接口按 rafsi 片段匹配时默认取第一个命中项没有做权重处理。解决在词典数据结构里给rafsi字段增加「关联词根列表」搜索时把所有候选项按词频或按是否出现在当前句子的 AST 中排序而不是按字母序。更稳妥的做法是返回候选数组让用户自己选前端展示「你也可能是要找A / B / C」。6. 进阶用法给工具链做回归验证与批量解析工具链能跑通只是第一步真正要长期维护得把「怎么验证它没坏」这件事也做起来。livla 这套组合的验证方式很朴素准备一批「句子 → 期望 AST 结构」的黄金测试集每次改完文法或词典字段就跑一遍全量回归。我一般这么组织测试const testCases [ { sentence: mi cliva le zdani, expectRule: bridi, expectSatisfy: (ast) ast.children[1].rule selbri }, { sentence: le nanla cu pendo mi, expectRule: bridi, expectSatisfy: (ast) ast.children[0].rule le_sumti } ]; testCases.forEach(({ sentence, expectRule, expectSatisfy }, index) { const result parser.parse(sentence); const passed result.ok result.tree.rule expectRule expectSatisfy(result.tree); console.log(case ${index}: ${passed ? PASS : FAIL}, sentence); });这类回归的价值在词典更新时特别明显——你加了一个新词条可能不小心把某个旧词条的形态还原规则顶掉了跑一遍测试集能立刻看到哪个句子的 AST 结构变了样。另一个值得做的进阶点是批量解析覆盖率统计拿一篇 Lojban 文本逐句解析统计「完全解析成功 / 部分失败 / 完全失败」的句子比例低于 85% 时基本可以断定文法文件有缺失或分词器有 bug。我现在的习惯是每次改完词典索引都强制跑一遍这组测试已经从「查完一个词发现不对再回头改」变成了「改完立刻知道哪坏了」。这套 livla 资源包里的 parser 和词典数据按照上面这套流程搭起来日常查词和验证句子结构都够用了希望帮到你。本文还有配套的精品资源点击获取