必须从isa段动态读取分隔符：第2位是子元素分隔符，第3位是元素分隔符，第105位是段结束符（索引从0起），不可硬编码；需用状态机解析以跳过引号内分隔符，避免split('~')导致字段错乱。
硬编码分隔符、直接 Split('~')、用 DTO 强映射 HI 段——这三件事做任意一件，解析 837/856 就大概率在生产环境凌晨三点炸锅。
怎么从 ISA 段动态读取分隔符
EDI 报文的分隔符不是写死的：ISA 段第 3 位是子元素分隔符（:），第 4 位是元素分隔符（*），第 106 位是段结束符（~），但这些值全可被发件方覆盖。比如某医院发来的 ISA*00* *00* *ZZ*123456789 *ZZ*987654321 *260424*1023*U*00501*000000001*0*T*>~，其中第 106 位是 > 而非 ~，硬写 Split('~') 会把整段当一个字段。
实操建议：
- 必须先截取前 107 字符（ISA 固定长度），再按位置取值：
isaLine[2]是子元素分隔符，isaLine[3]是元素分隔符，isaLine[105]是段结束符（索引从 0 开始） - 别用
Substring(2, 1)，用isaLine[2]更快且避免越界 - 拿到分隔符后，立刻验证是否为 ASCII 可见字符，防止控制字符混入导致后续解析静默失败
为什么不能 String.Split('~') 全报文切分
因为 X12 允许字段内容含段结束符，只要用双引号包围，比如 REF*BM*"ABC~DEF"~ —— 这里的 ~ 是数据，不是段尾。直接 Split('~') 会把这一段切成三块，破坏 REF 段结构，后续取 REF02 就崩出 IndexOutOfRangeException。
实操建议：
- 手写状态机比正则更稳：遍历字符，遇
"切换“引号内”状态，引号内跳过所有分隔符判断 - EdiFabric 内部就是这么做的，你若自己写，注意处理转义引号：
"He said ""Hi""."中的""算一个" - 别信“先 Replace 所有引号内 ~”的方案——字段本身含
""或嵌套引号时，Replace 会误伤
EdiFabric 里 X12_00501_837 类型为何总缺字段
不是库坏了，是模板没覆盖全。EdiFabric.Templates.X12 的 00501 版本对 HIPAA 837 支持较完整，但 00602 版本中 CLM 段的 CLM05–CLM07 子结构缺失，00702 版本甚至没生成 HI 段类。调用 EdiReader.Read<x12_00602_837>()</x12_00602_837> 时，遇到 CLM06 直接丢弃，不报错也不警告。
实操建议：
- 安装包只选
EdiFabric.Core+EdiFabric.Templates.X12，绝不要装EdiFabric.Templates.EDIFACT（医疗物流基本不用） - 用
EdiValidationResult.Errors检查解析结果，重点盯SegmentLengthExceeded和InvalidDate（如 D8 格式写成 MMDDYY） - 对 HI、REF、N1 这类循环段，别依赖强类型属性，改用
segment.GetLoop("2000B")+loop.GetSegments("HI")动态取，绕过模板缺失
HI 段解析为何总出错：字段顺序不一致是常态
不同保险商发的 837，HI 段字段顺序根本不一样：HI*BK:123456::ICD10 可能在 HI01–HI03，而另一家发的 HI*BF:789::CPT 却塞进 HI05–HI07。用 DTO 映射 HI01 到 DiagnosisCode，等于默认顺序固定，一换供应商就空指针。
实操建议：
- 放弃
HI强类型类，改用Dictionary<string string></string>接收原始字段对，例如new Dictionary<string string> { ["BK"] = "123456", ["ICD10"] = "F32.2" }</string> - 业务层再按规则匹配：先找
BK或BF，再根据后面版本标识（ICD10/CPT）决定如何入库 - 别提前把 HI 段拆成多个对象——同一笔索赔可能有 3 个诊断码，每个带不同版本，扁平化存
ClaimId, Sequence, Code, Type, Version更安全
最易被忽略的是首次加载模板的 JIT 编译开销：EdiReader.Read<t>()</t> 第一次调用要 200ms+，务必复用 EdiReader 实例，别每次 new；还有，SE 段只是事务结尾标记，不是数据段——把它当字段取，就等于把“句号”当成“最后一个词”。
