SourceGit 项目中字体设置导致软件崩溃问题分析与修复

问题背景

在 SourceGit 8.42 版本中，用户反馈了一个关于字体设置的严重问题：当用户在软件设置中指定一个不存在的字体名称时，如果该名称中包含连续空格，会导致软件无法正常启动。这个问题在 Windows 11 24H2 系统上被复现。

问题现象

用户发现，当在字体设置中输入：

1. "Microsoft Y"（单个空格）时，软件可以正常启动
2. "Microsoft Y"（两个连续空格）时，软件无法启动

唯一的区别就是字体名称中空格的数量。当出现问题时，用户需要手动修改配置文件才能恢复软件的正常使用。

技术分析

通过分析崩溃日志，我们发现问题的根源在于 Avalonia UI 框架的字体处理机制。具体来说：

1. 字体解析流程：Avalonia 在解析字体名称时，使用了一个字符串分词器(StringTokenizer)来处理字体名称中的各个部分。
2. 连续空格问题：当字体名称中包含连续空格时，分词器无法正确处理这种格式，导致抛出 System.FormatException 异常。
3. 异常传播：这个异常没有被捕获，最终导致应用程序崩溃。

解决方案

针对这个问题，我们采取了以下修复措施：

1. 输入验证：在保存字体设置前，对输入的字体名称进行规范化处理，去除多余的空格。
2. 异常处理：在字体加载过程中添加了更完善的异常处理机制，确保即使字体设置有问题，也能回退到默认字体而不会导致应用崩溃。
3. 默认字体保障：确保内置字体(Inter 和 JetBrainsMono)始终可用，作为最后的回退方案。

技术实现细节

修复的核心在于对字体名称的预处理：

// 规范化字体名称 - 去除多余空格
var normalizedFontName = fontName.Trim().Replace("  ", " ");

同时，在字体加载流程中添加了防御性编程：

try {
    // 尝试加载指定字体
    var typeface = new Typeface(normalizedFontName);
    // 使用字体...
} catch {
    // 回退到默认字体
    typeface = new Typeface("Inter");
}

经验总结

这个案例给我们带来了几个重要的经验教训：

1. 用户输入的不可信性：永远不要假设用户输入是规范的，必须进行严格的验证和规范化处理。
2. 防御性编程：关键路径上的操作必须有完善的错误处理机制，特别是涉及外部资源(如系统字体)的操作。
3. 回退机制的重要性：对于可配置项，必须设计合理的默认值和回退策略，确保系统在异常情况下仍能正常工作。

用户建议

对于使用 SourceGit 的用户，我们建议：

1. 更新到修复后的版本
2. 在设置字体时，避免使用连续空格
3. 如果遇到类似问题，可以手动编辑配置文件进行恢复

这个问题的修复不仅解决了特定场景下的崩溃问题，也提高了整个软件在异常情况下的健壮性，为用户提供了更好的使用体验。