trimend 不会误删中间的逗号，只删除末尾连续匹配的指定字符；例如 "a,,b,c," 调用 .trimend(',') 得 "a,,b,c"，而末尾含全角逗号、空格或零宽空格时则不生效。
TrimEnd 会误删中间的逗号吗？
TrimEnd 只作用于字符串末尾，不会碰中间字符。它按字符集合逐个匹配后缀，直到遇到第一个不在此集合中的字符就停止。所以 "a,b,c," 调用 .TrimEnd(',') 得到 "a,b,c"，但 "a,,b,c," 也会变成 "a,,b,c" —— 它只删末尾连续的逗号，不管前面有多少。
- 常见错误现象：
"item1,item2,item3,,"用.TrimEnd(',')后仍是"item1,item2,item3,"（因为最后两个逗号是连续的，它全删了）；但如果写成.TrimEnd(',', ' ')，可能意外把末尾空格也删掉 - 使用场景：清理拼接后遗留的尾随分隔符，比如循环拼接 CSV 字段后统一去逗号
- 参数差异：
TrimEnd(char)和TrimEnd(char[])行为一致，但传入数组时要注意别混入无关字符（比如不小心加了'\0'或控制字符）
为什么 TrimEnd(",") 有时没效果？
最常见原因是字符串末尾实际不是英文逗号，而是全角逗号 ，、空格、换行或不可见 Unicode 字符（如 \u200b 零宽空格）。TrimEnd 是严格字符匹配，一个都对不上就完全不删。
- 常见错误现象：调试时看到字符串显示为
"a,b,c,"，但.TrimEnd(',')返回原串 —— 复制出来粘贴到十六进制查看器，大概率发现末尾是\r\n或\u3001 - 实操建议：先用
.LastOrDefault()或.Substring(Math.Max(0, s.Length - 2))看末尾真实字符；或者用.TrimEnd(',', ' ', '\r', '\n')覆盖常见干扰 - 性能影响：传入字符数组比单字符略慢，但对普通业务字符串可忽略；避免传入过长数组（如上百个字符），CLR 内部会做线性扫描
Replace + EndsWith 比 TrimEnd 更安全？
当必须确保「仅删最后一个逗号」（哪怕后面还有空格或换行），TrimEnd 就不够用了。这时候得手动判断后缀再切片，Replace 不适合，因为它会全局替换。
- 使用场景：生成 SQL
IN子句时，字段列表末尾多了一个逗号，且不能动前面的格式（比如已有缩进或换行） - 实操建议：
if (s.EndsWith(",", StringComparison.Ordinal)) s = s.Substring(0, s.Length - 1);比正则快，也比TrimEnd精确 - 容易踩的坑：用
EndsWith必须指定StringComparison.Ordinal，否则在土耳其语等文化下可能误判；Substring前要检查长度，空字符串会抛ArgumentOutOfRangeException
TrimEnd 在 .NET Framework 和 .NET Core 行为一致吗？
行为完全一致，从 .NET Framework 2.0 到 .NET 8，TrimEnd 的逻辑没变过。但要注意：.NET 5+ 默认启用 string.Create 相关优化，极短字符串（TrimEnd 结果可能复用原字符串引用（返回 same object），而老版本总是新建实例 —— 这会影响引用比较，但不影响值语义。
- 兼容性影响：如果代码里写了
ReferenceEquals(s.TrimEnd(','), s)并依赖其结果，升级到 .NET 5+ 可能出问题 - 实操建议：永远用
==或.Equals()比较字符串内容，别依赖引用相等；测试时覆盖空串、单字符、全逗号等边界输入
字符串末尾的“逗号”未必是肉眼所见的那个字符，真正麻烦的是那些看不见的、文化相关的、跨平台不一致的空白和标点 —— 多打一行日志输出十六进制，比猜半天快得多。
