Stanford.NLP.CoreNLP是C#中较易上手的NER方案，但需.NET 6+、解压模型文件、单例复用CRFClassifier；中文需专用模型；Microsoft.ML仅支持粗粒度二分类；规则+词典法更稳定高效；务必显式处理文件编码与换行。
用 Stanford.NLP.CoreNLP 做基础 NER 识别，但要注意 .NET 版本兼容性
直接上 Stanford.NLP.CoreNLP 是 C# 里最接近开箱即用的方案，但它不是纯托管库——底层依赖 Java 运行时和模型文件。.NET 6+ 可以跑，但 net472 或更老版本容易卡在 JNI 加载失败或路径解析异常上。
实操建议：
- 优先用
dotnet new console -f net6.0新建项目，避免在旧框架下硬扛 - 模型文件（如
english.all.3class.distsim.crf.ser.gz）必须解压后放在可读路径，CRFClassifier不接受压缩包直读 - 初始化耗时明显（2–5 秒），别在循环里反复 new
CRFClassifier，应单例复用 - 中文 NER 需换模型（如
chinese.misc.distsim.crf.ser.gz），英文模型对中文基本无效
Microsoft.ML + 预训练管道能跑通，但实体粒度粗、不可定制
Microsoft.ML 的 TextClassificationTrainer 或 MultiClassClassificationTrainer 可以训一个“是否为人名”的二分类器，但本质是序列标注的简化版——它不输出 BIO 标签，也不支持地名/机构名等多类型区分。
常见错误现象：
- 把整句当一个样本喂进去，结果模型只学了“这句话有没有人名”，而非“哪几个字是人名”
- 用
FeaturizeText默认参数，词向量没对齐空格和标点，导致“张三，李四”被切为["张三，", "李四"]，逗号粘在人名后面 - 训练数据没做字符级对齐，标签序列长度和输入文本长度不一致，训练直接抛
ArgumentException
如果真要用，得自己写 IProcessor 实现字符级分词 + BIO 编码，工作量接近重写标注 pipeline。
绕过 NER 模型，用规则 + 词典快速提取（适合人名/地名有限场景）
如果你处理的是内部日志、工单或结构化程度高的文本（比如“客户：王建国，地址：杭州市西湖区文三路…”），规则法反而更稳、更快、更容易 debug。
实操建议：
- 人名用常见姓氏表 + 2–3 字正则：
@"(赵|钱|孙|李|周|吴|郑|王)、?[一-龥]{1,2}"，注意中文顿号、逗号都可能是分隔符 - 地名用行政区划词典（省/市/区三级）构建
HashSet<string></string>，再用IndexOfAny或 Aho-Corasick 算法批量匹配 - 避免用
String.Contains扫描全文——“海”会命中“上海”“海口”“青海”，得加前后边界判断（如\b上海\b，但中文无 \b，改用(?） - 词典加载进内存后，整个匹配过程不依赖网络、不加载模型，冷启动零延迟
别忽略编码和换行问题，File.ReadAllText 默认不是 UTF-8
很多 NER 结果乱码或漏识别，根本原因不在模型，而在文件读取阶段。Windows 记事本保存的文本默认是 GBK 或 UTF-8 with BOM，而 File.ReadAllText(path) 在没指定编码时会按系统区域设置猜，猜错就全崩。
必须显式指定：
- 读取前先用
File.ReadAllBytes检查 BOM：bytes[0] == 0xEF && bytes[1] == 0xBB && bytes[2] == 0xBF→UTF-8 - 否则 fallback 到
Encoding.Default（通常是 GBK），再转成统一 UTF-8 处理 - 换行符混用（
\r\n/\n）不影响 NER，但会影响基于行的预处理逻辑，建议统一.Replace("\r\n", "\n").Replace("\r", "\n")
NER 模型本身不关心编码，但输入字符串一旦是乱码，模型输出就是无意义字符——这点比选哪个库还关键。
