CSV中文乱码主因是编码不匹配，应通过检测文件头BOM（如EF BB BF为UTF-8 with BOM）确定真实编码，再用StreamReader显式指定Encoding读取；写入时按需选择UTF-8 with BOM（兼容Excel）或without BOM（跨平台），避免依赖默认编码。
CSV文件读取时出现中文乱码，大概率是编码没对上
Windows记事本默认用UTF-8 with BOM或GBK（取决于系统区域），而File.ReadAllText或StreamReader不显式指定编码时会 fallback 到UTF-8（无BOM）或系统默认编码，两者错位就直接显示“”或方块。别猜，先查BOM。
如何检测CSV真实编码（尤其带BOM的UTF-8/UTF-16）
靠文件头4字节就能判断，比依赖扩展名或用户声明可靠得多：
-
EF BB BF→UTF-8 with BOM -
FF FE→UTF-16 LE -
FE FF→UTF-16 BE - 前两字节是
00 00且第三字节非00→ 很可能是UTF-32 - 其余情况，默认按
GBK（中文Windows常见）或UTF-8尝试（建议优先试GBK）
实操建议：封装一个DetectEncoding方法，读取文件前4字节，返回Encoding实例，再传给StreamReader。别硬写new StreamReader(path)。
用StreamReader读CSV时必须传入明确Encoding
File.ReadAllLines和File.ReadAllText没有编码参数重载（.NET Core 6+才有），容易踩坑。稳妥做法是始终用StreamReader：
using var sr = new StreamReader(filePath, detectedEncoding);
string line;
while ((line = sr.ReadLine()) != null)
{
// 按,分割、处理引号转义等...
}
注意：detectedEncoding不能为null；若检测失败，至少 fallback 到Encoding.GetEncoding("GBK")（中文Windows环境）或Encoding.UTF8，别让程序抛DecoderFallbackException。
写CSV时也要主动指定编码，避免下次读又乱
用StreamWriter写入时，不传Encoding参数会默认用UTF-8 without BOM，但Excel打开可能仍乱码——因为Excel（尤其是旧版）默认按系统编码解析，不识别UTF-8 BOM。解决办法：
- 要兼容Excel双击打开 → 写成
UTF-8 with BOM：new StreamWriter(path, false, new UTF8Encoding(true)) - 要确保Linux/macOS脚本可读 → 用
UTF-8 without BOM，但需配套文档说明编码 - 内部系统间传输 → 统一用
UTF-8 with BOM最省事
BOM不是装饰，它是编码的“身份证”。漏掉它，等于把文件扔进编码迷宫里。
