核心问题: 你需要一个绝不将文本传输到第三方服务器的语法检查器吗？
RepoDaily 采用评分
RepoDaily 将该项目的采用分评为 91/100（强）：分数来自文章来源、安装路径、生产风险、差异化、许可证清晰度以及 AI/Agent 适配度。
包含 5 个来源、覆盖 3 类来源；如有 RepoDaily 独有模块，会进一步提高证据分。
检测到 5 个工作流步骤、5 个下一步动作，以及 2 个命令/安装信号。
趋势热度为 +590 stars；如内容中有 release、issue 或维护信号，会提高维护可信度。
采纳风险标记为 low，并包含 4 条安全说明与 3 条跳过条件。
3 个机会视角、3 个替代方案，以及 4 个类型化模块支撑差异化判断。
文章中包含许可证来源或许可证表述。
文章正文和元数据中检测到 3 个 AI/Agent 相关信号。
项目概览
Harper 是一个用 Rust 编写的英文语法检查器，由 WordPress.com 背后的 Automattic 公司维护。它的诞生源于一个明确的痛点：Grammarly 昂贵、侵入性强，而且会将你写的所有内容发送到远程服务器；LanguageTool 则需要大约 16 GB 的 n-gram 数据集，校对一篇中等长度文档需要数秒。Harper 选择了不同的路线——毫秒级校对，内存占用不到 LanguageTool 的五十分之一，所有文本处理完全在设备本地完成。
项目以多种独立产物发布：命令行工具 harper-cli、语言服务器 harper-ls（发布在 crates.io）、WebAssembly 构建 harper.js（通过 NPM 分发）、基于 Tauri 的桌面应用，以及 Obsidian 插件。语言服务器支持 VS Code、Neovim、Helix、Emacs 和 Zed，让开发者直接在现有编辑器中获得语法检查能力。
Harper 的架构亮点在于 Rust 核心被有意拆分为职责清晰的工作空间 crate：harper-core 承载校对引擎，harper-ls 提供语言服务器，harper-wasm 面向浏览器部署，harper-tree-sitter 和 harper-html 负责结构化文本解析，还有 harper-typst、harper-tex、harper-python、harper-asciidoc 等面向不同文档格式的专用 crate。这种分离使同一套语法引擎可以驱动编辑器插件、命令行工具、Web 应用或文档流水线，而无需重复逻辑。
项目采用 Apache 2.0 协议，允许商业使用、修改和再分发。结合完全本地化处理的特点，Harper 对于有严格数据驻留要求的组织——如受监管行业、机密文档起草，或单纯不想让自己的文字被用于训练语言模型的写作者——是一个可行的选择。
为什么现在变热
- 本期获得 590 颗星，趋势排名第 11，反映了开发者对云端语法工具本地替代方案的关注。
- 由 Automattic 支持——这家公司有深厚的开源积累，为项目提供了机构级别的持续维护。
- 明确以隐私为定位对标 Grammarly——README 指出 Grammarly 会将用户文本发送到其服务器，而 Harper 完全在设备上处理。
- 提供了足够小的 WebAssembly 构建，可在浏览器中加载，使得无后端的嵌入式语法检查成为可能。
- 通过语言服务器协议实现多编辑器集成——VS Code、Neovim、Helix、Emacs、Zed 开箱即用。
解决什么问题
- Grammarly 将用户文本发送到远程服务器，README 指出其隐私政策并不阻止将数据用于训练大语言模型。
- Grammarly 的建议被描述为缺乏上下文且经常出错，网络往返延迟拖慢了修改过程。
- LanguageTool 需要约 16 GB 的 n-gram 数据集和数 GB 内存，对轻量或嵌入式场景不友好。
- LanguageTool 校对中等长度文档需要数秒——Harper 将任何超出毫秒级的延迟都视为应报告的 bug。
- 云端语法服务为受监管行业和敏感文档带来合规与保密问题。
工作原理
- 根据环境选择安装方式：从 crates.io 安装 harper-ls 用于编辑器集成，或从 NPM 安装 harper.js 用于 Web 和 Node.js 场景。
- 在编辑器中进行配置——writewithharper.com 上有 VS Code、Neovim、Helix、Emacs、Zed 的专属设置页面。
- 打开文档，Rust 校对引擎在本地分析文本，毫秒级返回建议，无需任何网络往返。
- 在浏览器场景中加载 WebAssembly 构建，它足够小，可作为静态资源提供服务，无服务端组件。
- 可选：扩展引擎以支持新语言——核心设计为可扩展，README 欢迎英文以外的语言贡献。
工作空间架构：Rust 各 crate 如何协作
Harper 的 Cargo.toml 定义了一个包含 22 个成员的大型工作空间，每个成员处理特定职责。核心校对逻辑在 harper-core 中。语言服务器协议封装在 harper-ls 中，已发布到 crates.io。浏览器部署使用 harper-wasm，以 harper.js 名称在 NPM 上分发。结构化或代码相关文本的解析委托给 harper-tree-sitter、harper-html、harper-comments、harper-python、harper-literate-haskell 和 harper-ink。
文档格式支持分布在 harper-typst、harper-tex、harper-asciidoc 和 harper-html 中。工具类 crate 包括 harper-stats（指标）、harper-pos-utils（词性标注工具）、harper-thesaurus（同义词处理）、harper-brill（Brill 标注器逻辑）。桌面应用基于 Tauri 构建（harper-desktop/src-tauri），harper-git-commit 提供 commit 信息校对。
release 配置使用 opt-level 3、panic 设为 abort、fat LTO——这些选择优先考虑二进制体积和运行时速度。test 配置对本地 crate 应用 opt-level 1，对依赖应用 opt-level 3，在保持测试速度的同时不拖慢依赖密集的集成测试。
集成面：可以在哪里接入 Harper
- crates.io 上的 harper-ls —— 适用于任何支持 LSP 的编辑器的语言服务器。
- NPM 上的 harper.js —— 面向浏览器和 Node.js 嵌入的 WebAssembly 构建。
- Obsidian 插件 —— 独立仓库（harper-obsidian-plugin），有独立的下载计数。
- 桌面应用 —— 基于 Tauri 的原生应用，可独立使用。
- 编辑器文档 —— VS Code、Neovim、Helix、Emacs、Zed 各有专属页面，位于 writewithharper.com/docs/integrations/。
- harper-cli —— 命令行工具，可用于脚本和 CI 中对文本文件的校对。
最快的试用路径
如果你使用受支持的编辑器，最快的评估方式是安装 harper-ls 并将你的 LSP 客户端指向它。文档站点 writewithharper.com/docs/integrations/ 为 VS Code、Neovim、Helix、Emacs 和 Zed 提供了编辑器专属页面。
对于 Web 开发者，NPM 包 harper.js 提供 WebAssembly 构建。仓库的 package.json 要求数据 Node >= 22 和 pnpm ^10.6.3，开发脚本使用 Biome 进行格式化。README 确认 WASM 构建足够小，可通过 WebAssembly 在浏览器中加载，writewithharper.com 本身就是一个实时演示。
Obsidian 用户可从独立的 harper-obsidian-plugin 仓库安装插件。README 链接到 writewithharper.com/docs/integrations/obsidian 的专属文档。
Harper 与 Grammarly、LanguageTool 的对比
README 非常直白地将 Harper 与两个主要竞品对比。Grammarly 被描述为昂贵、侵入性强、建议缺乏上下文，且是隐私噩梦——所有文本都发送到其服务器。README 特别指出，Grammarly 隐私政策中不出售数据并不等于不会用于模型训练。
LanguageTool 被描述为能力出色但资源使用不切实际——需要约 16 GB n-gram 数据集，校对中等文档需要数秒。Harper 声称内存占用不到 LanguageTool 的五十分之一，校对在毫秒级完成。
另一个开源工具 Vale 专注于可配置的风格规则检查，而非语法纠正，因此与 Harper 的语法建议是互补关系而非直接替代。
谁适合关注
适合关注
- 希望在不传输数据到云端的情况下获得语法检查的个人写作者和开发者。
- 已标准化使用 VS Code、Neovim、Helix、Emacs 或 Zed 的团队，可受益于基于 LSP 的校对。
- 希望获得应用内语法建议的 Obsidian 用户。
- 需要通过 WebAssembly 嵌入无后端语法检查器的 Web 应用开发者。
- 对文本不得离开本地设备有合规要求的受监管行业组织。
可以先跳过
- 非英文内容——Harper 目前仅支持英文，尽管核心可扩展。
- 需要即刻获得英文以外多语言语法检查的用户。
- 更偏好云端 AI 改写和语气调节功能、而非基于规则的语法纠正的团队。
风险与注意事项
Apache 2.0 协议，由 Automattic 支持，完全离线运行，无网络依赖或数据传输。
- Apache 2.0 允许商业使用、修改和再分发，并包含专利授权。
- 所有文本处理在本地完成——README 确认无数据发送到服务器，WASM 构建在客户端运行。
- 已发布到 crates.io（harper-ls）和 NPM（harper.js），CI 徽章可见二进制构建、Web 构建和检查状态。
- 由 Automattic 支持，提供了超越单一维护者的机构连续性。
- README 明确表示性能回退被视为 bug，体现了质量优先的态度。
- 所有语法分析在本地机器上完成——无文本传输到任何服务器。
- WebAssembly 构建完全在浏览器中运行，无后端调用。
- Apache 2.0 协议允许源代码审计和修改以进行安全审查。
- README 直接对比 Harper 的本地处理与 Grammarly 的服务器模型及其数据训练隐患。
替代方案比较
| 方案 | 适用场景 | 代价 |
|---|---|---|
Grammarly | 你需要云端 AI 改写、语气调节和跨平台浏览器集成。 | 订阅制商业产品。 |
LanguageTool | 你需要英文以外的多语言语法支持，且能分配数 GB 内存和 16 GB n-gram 数据集。 | 免费开源或付费云服务。 |
Vale | 你想要一个专注于可配置风格规则而非语法纠正的散文检查器。 | 免费开源（MIT）。 |
这个趋势说明了什么
用 harper.js 在 Web 应用中嵌入语法检查
WebAssembly 构建足够小，可作为浏览器资源加载。Web 编辑器、CMS 草稿界面和表单密集型 SaaS 产品可以提供实时语法建议，而无需后端语法 API——既消除了延迟，也消除了数据隐私顾虑。
从 NPM 安装 harper.js，在浏览器测试页面中加载 WASM 模块，在 2,000 词文档上测量校对延迟，以确认毫秒级声明适用于你的目标环境。
在 CI 中校对文档和 commit 信息
工作空间包含用于 commit 信息校对的 harper-git-commit 和命令行工具 harper-cli。Typst、LaTeX、AsciiDoc、HTML 的文档流水线可以集成 Harper，在合并前捕获语法错误。
对示例文档目录运行 harper-cli，测量每 1,000 词的建议数量，并与当前审查流程对比。
贡献新的语言包
README 明确表示核心可扩展以支持其他语言，并欢迎贡献。拥有内部语言学专业知识的团队可以添加语言支持，并享有同样的本地化、低内存特性。
阅读 writewithharper.com/docs/contributors/introduction 上的贡献指南，以 harper-core 为基础为目标语言原型实现一组最小规则集。
RepoDaily 判断
Harper 是少有的让开发者可以毫无隐私顾虑地推荐的语法工具：Apache 2.0 协议、由 Automattic 支持、用 Rust 编写、完全在设备上运行。凭借多编辑器 LSP 支持、可浏览器加载的 WASM 构建和明确可扩展的核心，它值得任何对 Grammarly 云端模型或 LanguageTool 资源开销感到不满的人一试。