应先用Ude.CharsetDetector探测编码再读取文件，避免File.ReadAllText默认UTF-8无BOM导致中文乱码；情感分析优先调用Python.NET加载transformers预训练模型，注意Python环境路径配置与启动预热；分词依模型需求选择，transformers类模型宜跳过人工分词。
用 File.ReadAllText 读文件前先确认编码是否匹配
中文文本如果用 UTF-8 带 BOM 或 GB2312 保存，而代码里直接调用 File.ReadAllText(path)，大概率出现乱码，后续情感分析结果全偏——不是模型不准，是输入已经错了。
- 默认
File.ReadAllText按 UTF-8 无 BOM 解码，但 Windows 记事本存的“UTF-8”实际常带 BOM；遇到乱码，优先试File.ReadAllText(path, Encoding.UTF8)显式指定 - 老系统导出的文本（如 Excel CSV、某些 ERP 日志）可能用
Encoding.Default（即系统 ANSI），得换成Encoding.GetEncoding("GB2312")或"GBK" - 不确定编码时，用
Ude.CharsetDetector库（NuGet 包Ude）自动探测，比硬猜靠谱
别自己写情感词典匹配，优先用现成 NLP 库
用正则扫“好”“棒”“差”“烂”这种规则方式，在真实业务文本里准确率通常低于 60%——否定词（“不怎么好”）、程度副词（“极其糟糕”）、语境反转（“这个 bug 好得让我想辞职”）全处理不了。
- C# 生态里最稳的选择是调用 Python 的
transformers模型（如uer/roberta-finetuned-jd-binary-chinese），通过Python.NET在 C# 进程内加载，比 HTTP 调 API 更低延迟 - 轻量级场景可用
ML.NET训练二分类模型：准备几百条已标注的中文评论（正面/负面），用TextFeaturizer+SdcaLogisticRegressionBinaryTrainer，部署简单但泛化能力弱于预训练模型 - 完全离线且对精度要求不高，可试
ChnSentiCorp词典 +JiebaNet分词组合，但需手动处理否定和程度修饰，维护成本高
Python.NET 调用 transformers 时要注意路径和环境隔离
直接在 C# 项目里 PythonEngine.Initialize() 后 import transformers，十次有八次报 ModuleNotFoundError 或 ImportError: DLL load failed——根本原因是 Python 环境没对齐，不是 C# 写错了。
- 必须用
PythonEngine.PythonPath指向你 pip 安装了transformers和torch的那个 Python 环境（比如"C:\Python39\Lib\site-packages"不行，要设为"C:\Python39"） - Windows 上若装了多个 Python 版本，
PythonEngine.Initialize()前加Environment.SetEnvironmentVariable("PYTHONHOME", "C:\Python39")，否则它会随机绑定一个 - 模型首次加载极慢（>30 秒），且占用显存；务必在应用启动时预热一次，不要等用户点按钮才
pipeline(...)
中文分词不是必须前置步骤，但影响模型输入质量
像 roberta-base 类模型内部用 WordPiece 分词，直接喂原始中文句子没问题；但如果你用的是基于词粒度训练的模型（比如某些 LDA 主题模型或老式 SVM），没分词就等于把整段当一个 token，特征全废。
- 用
JiebaNet分词后拼空格再送入模型，适合适配词向量类模型；但注意JiebaNet默认词典不含网络新词（如“绝绝子”“尊嘟假嘟”），得手动AddWord - 用
HanLP（.NET 版本）更准，支持命名实体识别和依存句法，但体积大、启动慢，适合后台服务而非客户端 - 纯
transformers流程中，跳过分词反而更稳——让 tokenizer 自己切，避免人工分词和模型分词逻辑冲突
真正卡住人的往往不是算法，而是中文文本的编码混杂、Python 环境粘连、以及模型 tokenizer 和你预期的分词结果不一致。这三处多打两次断点，比调参有用得多。
