Typora红色下划线误报拼写错误怎么办？

Question

在使用Typora时，部分用户会遇到编辑器对正确拼写的英文单词（如专业术语、人名或技术词汇）显示红色下划线，误报为拼写错误。该问题通常源于Typora内置的拼写检查词典不完整或语言设置不当，尤其在使用非美式英语或特定领域术语时更为常见。尽管内容实际无误，但红色波浪线会影响写作体验与文档美观。如何有效识别并解决此类误报，避免手动忽略每个单词，是Typora用户普遍关注的实际问题。

Answer 1

1. 问题现象与初步识别

在使用Typora进行技术文档撰写时，部分用户发现某些正确拼写的英文单词（如“Kubernetes”、“PyTorch”、“ReactJS”或人名“Linus Torvalds”）被标记为拼写错误，显示红色下划线。这种误报现象并非Typora的程序缺陷，而是其内置拼写检查机制基于默认词典进行判断所致。Typora默认启用的是美式英语（en-US）词典，而专业术语、开源项目名称、非英语词汇等往往不在该词典范围内。

• 典型误报场景包括：技术框架名称（如TensorFlow）、编程语言变体（TypeScript）、公司名（GitHub）、缩写术语（CI/CD）等。
• 拼写检查功能由系统级或应用内嵌的Hunspell词典驱动，无法自动识别领域专有名词。
• 该问题在跨语言写作或多语种混合内容中尤为突出，例如中英混排文档中的英文术语。

2. 深层原因分析

要从根本上理解此问题，需从Typora的拼写检查架构入手。Typora依赖Electron框架构建，其拼写检查模块集成自Chromium引擎，使用操作系统提供的原生拼写服务或自带词典库。不同平台（Windows/macOS/Linux）处理方式存在差异：

操作系统	拼写检查来源	词典可定制性
macOS	系统级NSSpellChecker	高（可通过用户词典扩展）
Windows	Windows Spell Checker API	中（依赖UWP词典支持）
Linux	Hunspell + libhyphen	高（手动配置词典路径）

此外，Typora本身未提供图形化界面用于添加自定义词汇或切换行业专用词典（如医学、计算机科学），导致用户必须通过外部手段干预拼写检查行为。

3. 解决方案层级递进

1. 临时规避：关闭拼写检查
   进入 偏好设置 → Editor → Show spell check，取消勾选以禁用全局拼写检查。适用于对拼写准确性要求不高但追求视觉整洁的场景。
2. 语言切换：匹配文本语种
   若文档主要使用英式英语（en-GB）、加拿大英语（en-CA）等，可在 Preferences → Language 中切换对应语言，部分变体会包含更广泛的术语。
3. 添加用户词典：持久化自定义词汇
   Typora支持加载Hunspell格式的用户词典。用户可创建个人词典文件（.dic/.aff），并将专业术语逐行写入.dic文件，再在启动参数中指定路径。
4. 自动化脚本辅助：批量注入术语
   结合Python脚本扫描Markdown源文件，提取高频非词典词汇，自动生成用户词典条目，提升维护效率。

4. 高级配置与工程化实践

对于IT从业者而言，可将Typora拼写管理纳入个人知识管理体系。以下为一个典型的CI/CD风格流程图，展示如何实现术语一致性保障：

graph TD
    A[编写Markdown文档] --> B{是否含红色下划线?}
    B -- 是 --> C[提取疑似误报词汇]
    C --> D[查询内部术语库/Glossary]
    D -- 存在 --> E[加入本地Hunspell用户词典]
    D -- 不存在 --> F[提交至团队术语审核池]
    E --> G[重新加载Typora词典]
    G --> H[验证下划线消失]
    H --> I[提交版本控制]

该流程体现了DevOps思维在文档工程中的延伸——将拼写检查视为“质量门禁”，并通过可重复的机制减少人为干预。

5. 团队协作与标准化建议

在企业级技术文档协作中，应建立统一的术语规范。推荐做法如下：

• 制定组织级 technical-glossary.dic 文件，包含所有产品名、API术语、缩略语。
• 通过Ansible或Shell脚本部署该词典到团队成员的Typora配置目录（如 macOS: ~/Library/Application Support/abnerworks.Typora/dictionaries/）。
• 结合Git Hooks，在commit前运行拼写预检脚本，提示潜在术语不一致问题。

此举不仅解决红色下划线干扰，更提升了技术文档的专业性与一致性。