C#基于给定字符串列表分割文本时如何避免同列表子串引发的误分割

string.Split 传入多分隔符数组的匹配逻辑存在天然局限性：它会逐字符扫描源文本，在每个扫描位置依次遍历所有传入的分隔符，只要发现任意分隔符能和当前位置的文本匹配，就立刻在该位置执行切割，完全不考虑当前匹配的短分隔符是否属于某个更长分隔符的覆盖范围。
这种逻辑天然会优先命中短子串分隔符，因此会出现你遇到的误分割场景：扫描到第二行文本中"the "之后的位置时，刚好匹配到短分隔符"estate of"，就立刻在此处切分，最终留下孤立的"the"片段。

不需要针对特定分隔符编写硬编码判断，只需要将分割逻辑替换为支持最长优先匹配的正则方案即可，步骤可完全复用：

1. 分隔符预处理
   • 先对分隔符列表去重，消除重复项带来的冗余匹配开销
   • 将去重后的分隔符按字符串长度从大到小排序，保证长度更长的分隔符拥有更高的匹配优先级
   • 对每个分隔符执行Regex.Escape 转义，避免分隔符中包含.、(、*这类正则特殊字符时，出现匹配偏差
2. 正则实例构建
   • 将转义后的分隔符用|连接成分支匹配组，开启大小写不敏感选项，构建正则实例
3. 执行分割
   • 用构建好的正则对输入文本执行Split，后续再接上原逻辑的Trim、过滤空白片段的处理即可

针对你给出的示例场景，预处理后的分隔符顺序为：长度13的"the estate of"、长度9的"estate of"、长度8的"in trust"、长度2的"or"，拼接生成的正则模式为：
the\ estate\ of|estate\ of|in\ trust|or
由于正则的分支匹配是按顺序尝试的，引擎在扫描到文本开头位置时，会优先尝试匹配排在最前面的长分隔符"the estate of"，而不是匹配藏在长字符串内部的短分隔符"estate of"，从根本上避免了短子串提前触发的误分割。

注意：该方案默认长分隔符本身为有效分割标记，即匹配到长分隔符时会正常执行切割。如果你的业务逻辑要求长分隔符仅用于屏蔽内部的短分隔符、本身不触发切割，只需要在预处理时将长分隔符从实际分割列表中移出作为排除项即可，依然不需要针对特定字符串编写专属规则。

内容的提问来源于stack exchange，提问作者user2191393。