应使用 StreamReader 流式读取配合 yield return 惰性解析，显式处理 BOM，轻量过滤后封装校验结果为 (lineNumber, line, isValid, reason)，正则仅作格式提取，语义校验用 C# 代码，规则热插拔通过 JSON+表达式引擎实现，失败时提供上下文高亮反馈。
怎么用 C# 读取文本文件并逐行校验声明真实性
直接读文件再逐行解析是最常见起点，但别急着写 File.ReadAllLines——它会把整个文件加载进内存，大文件（比如几百 MB 的日志或导出数据）容易触发 OutOfMemoryException。真正稳的做法是用 StreamReader 流式读取，配合 yield return 做惰性解析。
常见错误现象：用 File.ReadLines 后直接 .ToList() 或 .Count()，这等于又全加载了；或者没处理 BOM（字节顺序标记），导致首行开头出现 \ufeff，让正则匹配或字符串比较失败。
- 用
new StreamReader(path, Encoding.UTF8, detectEncodingFromByteOrderMarks: true)显式支持 BOM - 校验逻辑尽量轻量：先做快速过滤（如跳过空行、注释行），再进业务规则
- 每行校验结果建议封装成
(int lineNumber, string line, bool isValid, string? reason)这类结构，方便后续聚合或定位
C# 正则 + 自定义规则怎么组合验证“声明”语义
纯正则能解决格式问题（比如邮箱、日期、编号格式），但“声明真实性”往往涉及语义约束：例如“订单状态为 Shipped 时，发货时间不能为空且早于当前时间”。这类判断必须脱离正则，靠 C# 代码执行。
使用场景典型分两类：一类是固定模式（如 "ID:[0-9]+;STATUS:(Pending|Shipped|Cancelled);SHIPDATE:[0-9]{4}-[0-9]{2}-[0-9]{2}"），可用 Regex.Match 提取字段后二次校验；另一类是自由文本描述（如 "用户张三已于2024-05-20完成实名认证"），得靠 NLP 预处理或关键词+上下文规则（比如找 "已完成" + "实名认证" + 日期提取）。
- 避免在循环里反复编译正则：用
static readonly Regex s_pattern = new(@"...", RegexOptions.Compiled) - 提取字段后务必检查
match.Success，否则match.Groups["xxx"].Value会抛IndexOutOfRangeException - 日期解析不用
DateTime.Parse，改用DateTime.TryParseExact并指定文化信息（CultureInfo.InvariantCulture），防止本地化导致解析失败
如何让校验系统支持热插拔规则而不重启程序
硬编码所有规则会导致每次加一条新声明类型就得发版。可行方案是把规则定义成 JSON 配置 + 小段可执行表达式，运行时动态加载。
参数差异关键在表达式引擎选型：System.Linq.Expressions 太重、难调试；NCalc 或 FastExpressionCompiler 更轻量。但注意：任何表达式引擎都默认不支持访问外部变量或方法，必须显式传入上下文对象（比如 new { LineNumber = 123, Fields = new Dictionary<string string>() }</string>）。
- 配置里别存裸 SQL 或路径，避免注入风险；字段名统一转小写，避免大小写敏感问题
- 表达式中禁止调用
File.ReadAllText、Environment.GetEnvironmentVariable等副作用操作 - 首次加载规则时缓存编译后的委托，后续直接
func(context) → bool调用，别每次重新 parse
校验失败时怎么准确定位并反馈给非技术人员
开发觉得 "line 42: invalid date format" 很清楚，但业务方只认“第3页表格第5行的发货时间填错了”。所以输出必须带原始上下文：前 2 行、本行、后 2 行，并高亮可疑字段。
性能影响常被忽略：如果每行都去查数据库验证“用户是否存在”，IO 会拖垮整个流程。正确做法是预加载 ID 集合到 HashSet<string></string>，或用布隆过滤器粗筛，再对疑似无效 ID 单独查库。
- 错误信息里禁用技术术语：把
FormatException改成"发货时间格式应为 YYYY-MM-DD，当前值：'2024/05/20'" - 行号从 1 开始计数（不是 0），且和文本编辑器显示一致；若文件含 DOS 换行符
\r\n，确保按\n切分时行号计算准确 - 批量校验时别等全部跑完才输出，用
IProgress<validationresult></validationresult>实时推送进度和首个错误，避免用户干等
最麻烦的其实是“声明”的定义本身模糊——同一份文件里可能混着法律条款声明、API 响应断言、人工录入备注。没有统一 schema，就只能靠行首标识（如 [ASSERT]、[LEGAL]）分流处理。这点很容易被一开始忽略，直到上线后发现 30% 的“声明”根本不在预期格式里。
