开发者为什么需要 Harper：一款离线优先的 Rust 英语语法检查工具

开发者为什么需要 Harper一款离线优先的 Rust 英语语法检查工具【免费下载链接】harperOffline, privacy-first grammar checker. Fast, open-source, Rust-powered项目地址: https://gitcode.com/GitHub_Trending/har/harperHarper 是一款离线优先、注重隐私的开源英语语法检查工具基于 Rust 编写毫秒级完成检查适合写代码注释、技术文档、提交信息与博客文章的开发者使用。它把校对这件事完全放在本地设备上不联网、不上传、不停顿用起来更像一个顺手的编辑助手而不是一个需要讨好的在线服务。一个深夜的提交信息暴露了两个问题想象这样一个场景深夜提交代码Git 提交信息里敲下Fixes typos in the document第二天打开仓库才意识到单引号用错了位置。类似的还有 PR 描述里的 This fixs the issue、技术文档里的 an unique approach。英文不是母语时这类错误几乎防不胜防——它不是态度问题而是缺少一个能随时提醒你的工具。于是你自然会想装个在线语法检查器不就行了但问题接踵而至。首先你想检查的内容往往正在打字机上——可能是没写完的代码注释、内部的架构文档甚至包含敏感信息的日志片段而在线工具的运作方式恰恰是把这些内容传回云端。其次每次检查都要经历一次网络往返改一行再看一眼的节奏被彻底打乱。市面上的主流工具在设计之初就没把开发者当主角。Grammarly 价格不菲、建议经常脱离上下文数据还要经过它的服务器LanguageTool 足够强大却要下载约 16GB 的 n-gram 数据集内存占用惊人检查一篇中等长度的文档也要等上好几秒。Harper 的诞生正是作者在多年受这类工具折磨之后的回应它只做一件事——在本地、立刻、准确地检查你的英文。它是什么Harper 的定位与设计取舍Harper 是一个完全离线运行的英语语法检查引擎核心用 Rust 编写。它负责的不只是拼写还包括语法错误、标点误用、句子结构、冠词搭配、词性误用等一整套问题。得益于 Rust 的性能和紧凑的内存模型它检查一篇文档只需要毫秒级时间内存占用大约是同场景下 LanguageTool 的五十分之一。体积小带来的另一个好处是整个引擎能编译成 WebAssembly在浏览器里直接运行连安装依赖这一步都可以省掉。也就是说Harper 既是一个命令行工具、一个语言服务器也能以 WASM 的形式嵌入任何网页应用。从拼写到标点一次检查覆盖哪些问题假设你在 Markdown 里写了这么一句Theres a error in this document, it should be fix by tommorow. Harper 会一次性标出四处问题Theres应写成Theresa error的冠词应为anshould be fix是被动语态误用tommorow是拼写错误。它并不是简单对照词典而是对句子做词性分析后再判断哪里不对劲这也是它能发现冠词、语态这类纯拼写检查器看不到的问题的原因。如果你打开设置会看到全部 728 条检查规则按主题分组陈列专有名词的大小写、缩略语的写法、复合词的拼写、冠词的使用……每条规则都可以单独关闭或恢复默认。规则多不意味着打扰多——遇到不符合语境的建议关掉对应那一条即可不必整体禁用。规则引擎可解释、可扩展Harper 的检查体系由两类构件组成Linter负责通用问题PatternLinter负责看到某种词形组合就报警的模式类规则后者被包含在前者之中。对开发者而言这意味着语法检查不是一个不可干预的黑盒。这些规则以 Rust 文件和.weir规则文件的形式存放在仓库的harper-core/src/linting/目录下每一条都能读、能改、能新增。社区想要增加一种新的检查类型通常只需要照着现有规则写一份新文件。毫秒级响应与五十分之一内存性能从哪来把三种工具的取舍放在一起看会更清楚工具检查方式典型代价Grammarly云端处理网络往返、订阅费用、文本上传LanguageTool本地 n-gram 数据集约 16GB 数据集、高内存、秒级延迟Harper完全本地毫秒级响应、内存约为前者的 1/50正是因为不需要等待网络、不需要加载巨型数据集Harper 才能做到边打字边出结果。项目甚至把检查耗时长明确视为 bug而不是可接受的性能波动——这种态度本身就说明了它的优化优先级。实际用起来从桌面到浏览器再到博客后台桌面应用最直观的体验Harper 提供了独立的桌面版应用打开就是一个简洁的 Markdown 编辑器。错误以波浪线标在原文中右侧的问题面板列出每一条错误和修改建议点击即可一键替换。体验路径很直接启动应用 → 粘贴或书写英文 → 看右侧面板逐条处理建议 → 接受替换。对于不习惯在编辑器里折腾插件的用户这是最省事的第一步。浏览器扩展GitHub 评论区里的实时校对技术交流的一大主战场是 GitHub 的 Issue 与 PR 评论区。Harper 的浏览器扩展能在这个场景里实时标出错误——包括teh这类拼写错误和to to这类重复词——并且理解 Markdown 语法不会把代码块当成正文来检查。同样的检查能力也覆盖 Reddit、Gmail、WordPress、Office 在线版等常用网页凡是需要打英文的地方它都在后台悄悄盯着。WordPress 与 Obsidian写作场景的两块拼图如果你用 WordPress 写博客Harper 会以侧边栏的形式出现左侧正文实时标错右侧列出错误列表与替换建议甚至可以逐条接受或忽略。界面上那句在你点击发布之前数据不会离开 WordPress的提示把离线原则讲得很清楚。而如果你习惯在 Obsidian 里记笔记同样能找到对应的插件。写英文笔记时遇到an error这类冠词问题它会直接弹窗给出 Replace with a 的修正入口几乎不打断书写节奏。如果你是重度编辑器用户Harper 的覆盖也足够广VS Code、Neovim、Helix、Emacs、Zed 都可以通过harper-ls语言服务器接入harper.js则提供了 WASM 版本可以把同样的检查能力嵌入自己的网页应用。上手前需要知道的几个事实目前只支持英文。多语言支持依赖社区贡献内核在设计上预留了扩展点但短期内不要指望它检查中文。长文档首次加载会有一次性开销。词典加载完成前检查可能稍慢这是正常现象如果持续明显变慢官方把它视为 bug欢迎提交 issue。harper-cli还很实验性。它适合接入 CI 做批量检查但功能偏朴素自定义词典、机器可读输出等还在路上。规则建议不一定都符合语境。728 条规则默认全开遇到误报时在设置里单独关闭即可不必整体禁用。支持自定义词典。专有名词、品牌名这类词可以加进自己的词典避免被反复标红。想自己动手可以从这里开始如果这篇文章让你想试一试动手成本并不高。克隆仓库后根目录的 README 是很好的起点里面有完整的集成文档清单harper-core目录是引擎核心fuzz/目录放着模糊测试目标供想研究健壮性的人参考。git clone https://gitcode.com/GitHub_Trending/har/harper想深入的话可以到harper-core/src/linting/里挑一条感兴趣的规则文件读一读看看别人是怎么把一条语法规则写成代码的。为项目新增规则或修复性能问题都是不错的贡献方向。把语法检查从云端搬回本地这件事 Harper 做得很彻底——它不靠功能数量取胜而是靠零延迟、零上传、可读可改这三个朴素特性真正融进了开发和写作的日常流程。下一步其实很简单从你最常用的那个平台装一个插件拿一篇真实的英文文档测一测感受一下它在你本地上秒出结果的体验。【免费下载链接】harperOffline, privacy-first grammar checker. Fast, open-source, Rust-powered项目地址: https://gitcode.com/GitHub_Trending/har/harper创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考