用 StreamReader 流式读取替代 File.ReadAllText，配合 MemoryMappedFile 实现大文件低内存处理；预处理统一汉字变体、定制虚词表；用 PriorityQueue 替代 LINQ 排序；借助 EastAsianChronologies 库精准转换跨朝代纪年。
读取大文本文件时内存爆掉怎么办
直接用 File.ReadAllText 加载几 GB 的古籍 OCR 文本，程序大概率在 OutOfMemoryException 里跪下。数字人文项目常遇到单文件超 500MB 的扫描本转录文本，得绕开“全量加载”这个坑。
实操建议：
- 用
StreamReader按行或按块流式读取，配合ReadLine()或ReadBlock()，内存占用基本稳定在几 MB - 避免把整份《四库全书》文本塞进一个
string—— .NET 的字符串是不可变的，中间拼接、正则替换都会反复复制内存 - 如果必须全文索引，改用内存映射文件：
MemoryMappedFile.CreateFromFile，它不把内容真搬进托管堆，而是靠操作系统页表映射
中文古籍分词不准，正则也匹配不上怎么办
用 Regex.Replace(@"[^\u4e00-\u9fa5a-zA-Z0-9\s]", "") 清洗文献，结果把「〇」「廿」「卌」这些传统数字干掉了；更麻烦的是「之乎者也」类虚词和现代标点混杂，标准分词器（如 HanLP.NET）对明清刻本识别率常低于 60%。
实操建议：
- 先做字符级预处理：用
String.Normalize(NormalizationForm.FormC)统一全角/半角、兼容汉字变体（比如「爲」→「为」） - 虚词停用表不能照搬现代汉语，得自己建——从《佩文韵府》《经籍籑诂》里抽高频助词、语气词，存成
HashSet<string></string>，比正则快且可控 - 遇到「某甲曰」「右某」这类固定格式，写专用解析器比通用 NLP 更靠谱；例如用
Span<char>.IndexOf("曰")</char>定位对话起始，比跑一遍 ML 模型省资源
统计词频后排序慢，LINQ OrderByDescending 卡住
对百万级词频字典调用 dict.OrderByDescending(kvp => kvp.Value)，CPU 占满、等一分钟不出结果——这不是算法问题，是默认 LINQ 把整个 IEnumerable 拖进内存再排序，而词频字典本身可能已占几百 MB。
实操建议：
- 换
PriorityQueue（.NET 6+），边统计边维护 Top-K，内存和时间都压到 O(n log k) - 如果只要前 100 高频词，别先
GroupBy全量聚合，改用Dictionary<string int></string>+ 手动更新最大堆，避免 LINQ 的装箱和枚举开销 - 注意字符串键的哈希碰撞：古籍里大量同音字（如「後」「后」），用
StringComparer.Ordinal替代默认比较器，避免文化敏感比较拖慢哈希表
跨朝代文本时间归一化总出错
把「康熙三年」「建炎元年」「大正十五年」转成公元年份时，硬编码年号表结果漏了西夏「天授礼法延祚」、越南「光中」这种冷门纪年，DateTime.Parse 直接抛异常。
实操建议：
- 别自己写年号转换逻辑——用现成的
ChineseCalendar（仅支持农历）不够，得引入轻量库如EastAsianChronologies，它把年号、干支、公历三者映射做成只读查找表 - 识别年号时别依赖正则模糊匹配，先用精确前缀树（
ReadOnlySpan<char></char>+Span<char>.StartsWith</char>）查已知年号列表，再 fallback 到规则引擎 - 注意「同治」在清朝和日本都是年号，上下文决定归属；简单方案：加个
regionHint参数，传入文件元数据里的「来源机构：国图/东洋文库」来切换解析策略
古籍文本的噪声不是 bug，是史料特征。所有清洗逻辑都得留后门——比如保留原始行号、OCR 置信度字段、异体字标注，否则后期人工校勘时会发现：机器删掉的，恰恰是版本学关键线索。
