“我每天都在使用 RSS 和 Git，还会用 Docker 部署服务”
匹配后拆分为： “我每天都在使用 " RSS " 和 " Git “，还会用 " Docker " 部署服务"匹配规则：长词优先，一词一次术语匹配看着简单，实际落地时有很多细节需要打磨。长词优先如果一个术语同时匹配了「AppleScript」和「Script」，你肯定希望在文本中出现AppleScript时链接到 AppleScript，而不是被Script截胡。做法是：把所有候选词按长度降序排列，长的先匹配。匹配完后标记已用，不再参与后续节点的扫描。每篇文章只链接一次同一个术语在一篇文章里经常出现多次——比如「Docker」可能在文章开头、中间、末尾都出现过。如果每次出现都加上链接，视觉上会非常杂乱，而且没有任何意义。同一个术语 ID 在全文中只链接第一次出现的位置。这个逻辑用一个usedIds: Set来追踪，遍历文本节点时全局共享。跳过哪些节点不是所有文本都适合做术语链接。我维护了一份跳过清单：和——代码块里的名词是代码的一部分，不是自然语言——已经包裹在链接里的文本，不能再套一层链接（HTML 不允许嵌套）到——标题区域文字有限，加链接显得冗余、——非可见内容、、、——表单控件里的文本ASCII 术语的边界检查对于全英文的术语（比如RSS、Git、AI），还需要做单词边界检查——确保RSS匹配的是独立的RSS，而不是夹杂在RSSFeed这个字符串里。做法是检查匹配位置前后一个字符是否属于[\w]（字母、数字、下划线），如果前后紧挨着其他单词字符，则跳过这次匹配。重叠匹配的处理多个术语可能在同一段文本中出现位置重叠。比如术语表中同时有「GitHub」和「Git」，如果文本是「GitHub Pages」，正确的行为应该是匹配「GitHub」而不是「Git」。我的做法是将所有候选匹配按起始位置排序，然后从前到后取不重叠的匹配——起始位置大于等于上一个匹配的结束位置时才纳入结果。URL 决策树匹配到术语之后，链接指向哪里？我设计了一个优先级递减的决策链：1. langs[lang].url — 该语言下自定义 URL（如指向官方中文文档） 2. entry.url — 顶层自定义 URL（如产品官网） 3. 自动拼接 Wikipedia URL — 按语言选择子域名 + wikiPath为什么需要自定义 URL？有些术语没有对应的 Wikipedia 页面（比如一些小众开源工具），或者 Wikipedia 页面内容过于简略，指向官方网站或文档是更好的选择。目前大约有 15% 的术语配置了自定义 URL，专门处理这类情况。Wikipedia URL 的拼接规则也很直接：语言生成的 URLzhhttps://zh.wikipedia.org/wiki/{wikiPath}zh-twhttps://zh.wikipedia.org/wiki/{wikiPath}enhttps://en.wikipedia.org/wiki/{wikiPath}繁体中文和简体中文共用中文维基百科，只是 URL 编码后的路径可能不同（取决于词条本身的繁简体设置）。为什么大部分链接指向维基百科？因为维基百科具有以下优势：覆盖面广——绝大多数技术术语都有独立词条，无需手动维护；多语言支持——根据文章语言自动匹配对应子域名，中文/英文/繁中读者都能看到母语解释；链接稳定——维基词条 URL 受重定向保护，不会轻易失效。对于少数没有对应维基页面或维基词条过于简略的术语（约占 15%），我会通过自定义 URL 手动指定官网或更权威的文档。这样既保证了绝大多数场景的自动化，也保留了特殊情况的灵活处理空间。辅助工具：审计脚本与术语总览页除此之外，要维护一套术语表，需要工具来辅助发现「有哪些应该收录但还没收录的术语」。audit-glossary.ts这个脚本会扫遍所有文章正文，用正则找出高频出现的英文大写词组、缩写、混合大小写的产品名等候选词，然后对照现有术语表，输出一份「未注册高频术语」报告。比如