StreamReader 读 ini 乱码因默认 UTF- 8 无 BOM 无法兼容 GB2312 或 UTF- 8 带 BOM 文件，须显式指定 Encoding；记事本“ANSI”即 GB2312，“UTF-8”实为 UTF-8+BOM；推荐 File.ReadAllLines(path, Encoding) 并统一用 UTF- 8 或检测 BOM。
为什么 StreamReader 直接读 ini 会乱码
因为 windows 默认的 ini 文件（尤其用记事本保存的）大概率是 gb2312 或 utf-8 带 bom，而 c# 的 streamreader 默认用 utf-8 无 bom 解码——遇到 gb2312 编码的中文就全变成，utf-8 无 bom 文件若被误判为 ansi 也会崩。
- 别依赖
new StreamReader("a.ini")的默认编码，它不看文件实际编码 - 记事本另存为时选“UTF-8”实际存的是 UTF-8 + BOM；选“ANSI”在简体中文系统下就是 GB2312
- 用
File.ReadAllLines(path, Encoding)比StreamReader更稳，少一层流缓冲干扰
用 GetPrivateProfileString 读中文要加 Unicode 版本声明
Win32 API 的 GetPrivateProfileString 有 ANSI 和 Unicode 两个入口，C# P/Invoke 默认绑定到 ANSI 版，传入中文路径或 section/key 就直接返回空或乱码。
- 必须显式调用
GetPrivateProfileStringW（末尾带 W），并用[DllImport("kernel32.dll", CharSet = CharSet.Unicode)] -
lpReturnedString缓冲区要用StringBuilder，容量至少 32767，别用 string —— API 是通过指针写入的 - 如果 ini 路径含中文，确保路径字符串本身没被 .NET 内部转义或截断（比如用 @”” 字符串字面量）
自己解析 ini 时，section 和 key 的中文匹配要忽略首尾空白和大小写
ini 格式本身不区分大小写，但用户手写时可能混用空格、全角 / 半角冒号、等号前后空格，导致 line.StartsWith("[ 中文 Section]") 失败。
- 用正则
^s*[(.+?)]s*$提取 section 名，再用.Trim()清理 - key-value 行用
line.Split(new char[] {'=', ':'}, 2)拆分，取[0].Trim()作 key，[1].Trim()作 value - 比较时统一转小写 +
StringComparison.OrdinalIgnoreCase，避免"DBName"和"dbname"对不上 - value 中的中文反斜杠（如
路径 =C: 中文目录）不用额外转义，ini 不是 JSON
WritePrivateProfileString 写中文失败？检查目标 ini 是否被记事本“悄悄改过”
很多问题不是代码错，而是你用记事本编辑过 ini 后，它偷偷把文件编码从 UTF-8 换成了 GB2312，而 WritePrivateProfileStringW 只负责写宽字符，底层仍按当前文件编码落盘——结果就是新写入的中文在 GB2312 文件里变乱码。
- 用 VS Code 或 Notepad++ 查看文件真实编码（右下角），不是看“另存为”菜单里的选项
- 首次创建 ini 时，用
File.WriteAllText(path, "", Encoding.UTF8)显式初始化为空 UTF-8 文件（带 BOM 更稳妥） - 避免用记事本二次编辑；若必须，保存时务必选“UTF-8”且确认右下角显示是 UTF-8，不是“UTF-8 with BOM”和“UTF-8”混用
最麻烦的永远不是读写逻辑，而是 ini 文件在不同编辑器、不同 Windows 版本、不同用户操作习惯下，编码状态神出鬼没。盯住文件本身的编码字节（用十六进制查看器看开头是否 EF BB BF），比猜 Encoding.Default 可靠得多。
