environment.newline仅表示当前系统默认换行符，读取跨平台文本需手动标准化为”n”；推荐用replace(“rn”,”n”).replace(“r”,”n”)统一处理；writeline()自动适配平台，避免硬编码换行符。
用 Environment.NewLine 生成当前平台换行符，但读取时不能依赖它
很多开发者误以为 Environment.NewLine 能自动“适配”输入文本的换行格式——其实它只反映**当前运行环境**的默认换行符（windows 是 "rn"，linux/macos 是 "n"），和你读进来的文件无关。读取跨平台文本时，必须主动识别并标准化。
读取时统一转成 "n" 最省事也最安全
无论源文件是 "rn" 还是 "n"，甚至混用（比如 "rnrnn"），统一替换成单个 "n" 后再处理，能避免后续逻辑（如按行分割、正则匹配）出错。
- 用
text.Replace("rn", "n").Replace("r", "n")即可覆盖所有常见情况（windows、Linux、旧 Mac） - 不要只用
text.Replace("rn", "n")：遗漏仅含"r"的老式 Mac 文本，或纯"n"中夹杂"r" - 如果性能敏感且确定来源只有 CRLF/LF，可用
String.Split(new[] { "rn", "n", "r" }, StringSplitOptions.None)，但注意Split会丢弃空行信息，不如先替换再Split('n')
StreamReader 默认已处理换行符，但行为有隐含前提
StreamReader.ReadLine() 确实会自动识别 "rn"、"n"、"r" 并返回不带换行符的字符串——但它**只对逐行读取有效**。一旦你用 ReadToEnd() 拿到完整字符串，换行符原样保留，仍需手动清洗。
- 推荐场景：逐行处理日志、配置、CSV 等文本 → 直接用
ReadLine()，不用管换行符差异 - 避坑点：用
ReadToEnd()后调Split('n')→ 可能切出带"r"的行尾，导致后续 trim 失效或正则匹配失败 - 编码注意：确保
StreamReader构造时指定了正确编码（如new StreamReader(path, Encoding.UTF8)），否则 bom 或乱码可能干扰换行符识别
写入时别硬写 "rn"，优先用 StreamWriter.WriteLine()
硬编码 "rn" 会让程序在 Linux 上输出 Windows 风格换行，违反平台惯例；而直接拼 "n" 又可能让 Windows 用户用记事本打开时显示为一行。最稳妥的方式是交给 StreamWriter 处理：
-
sw.WriteLine("hello")会自动使用Environment.NewLine，输出符合当前平台习惯的换行符 - 如果明确需要跨平台一致（比如生成 http 响应体、json 文件），才显式用
"n"——但必须文档注明，并确保所有消费方都接受 LF - 避免
sw.Write("hellorn")：绕过StreamWriter的换行逻辑，失去平台适配能力
真正容易被忽略的是：**换行符标准化必须发生在“解析前”而非“显示后”**。比如从网络接收 JSON 字符串，里面字段值含 "rn"，若等到 ui 层再处理，可能已被 HTML 渲染或日志框架截断。该清洗的地方，一步到位。