ToString("C") 配合显式 CultureInfo 是最稳妥的货币格式化方式，能自动适配本地化规则（如符号位置、小数位、负数格式），避免硬编码导致的多语言和财务合规风险。
直接说结论：用 ToString("C") 配合 CultureInfo 是最稳妥的方式，硬写符号或小数位数会出错——尤其在多语言环境或财务场景下。
为什么 ToString("C") 比拼字符串更可靠
很多人图省事写 $ + value.ToString("F2")，但这样既不支持本地化（比如德国显示 €1.234,56），也不处理负数格式（有些地区用括号）、货币符号位置（日语是「¥1,234」，不是「1,234 ¥」），甚至会忽略小数位数规则（JPY 本就不该有小数）。
真正起作用的是当前线程的 CultureInfo，而 "C" 格式符会自动读取它：
var amount = 1234.5m;
Console.WriteLine(amount.ToString("C", new CultureInfo("de-DE"))); // → "1.234,50 €"
Console.WriteLine(amount.ToString("C", new CultureInfo("ja-JP"))); // → "¥1,234"
CultureInfo 传哪里？别只靠 Thread.CurrentThread.CurrentCulture
默认文化设置容易被意外修改（比如 ASP.NET Core 中间件、WPF 线程切换、甚至第三方库调用），靠全局设置不保险。
- Web API 返回 JSON 时，
ToString("C")默认走服务器文化，不是用户浏览器语言 - WinForms/WPF 绑定中，控件可能用 UI 线程文化，但数据源在后台线程生成
- 数据库查询后直接 ToString，没显式传
CultureInfo，就依赖当前线程上下文
实操建议：显式传参，不依赖隐式状态：
amount.ToString("C", CultureInfo.GetCultureInfo("zh-CN")) // 明确指定
常见错误：用 NumberFormatInfo 手动改 CurrencySymbol 却漏了其他字段
有人想“微调”货币符号，就 new 一个 NumberFormatInfo，只设 CurrencySymbol = "¥"，结果千分位变成英文逗号、小数点消失、负数显示成 "-¥123" —— 因为 NumberFormatInfo 不继承区域规则，所有字段都得手动配全。
更安全的做法是基于已有文化复制再改：
var cn = (NumberFormatInfo)CultureInfo.GetCultureInfo("zh-CN").NumberFormat.Clone();
cn.CurrencySymbol = "¥"; // 其他如 CurrencyDecimalSeparator、CurrencyGroupSeparator 自动保留
但注意：这种改法仍不如直接换文化 ID 稳定，尤其涉及汇率、会计四舍五入模式（CurrencyPositivePattern）等深层行为时。
性能和兼容性提醒：别在循环里反复 new CultureInfo
CultureInfo.GetCultureInfo("en-US") 是线程安全且带缓存的，推荐用；而 new CultureInfo("en-US") 每次都新建对象，GC 压力大，.NET 6+ 还可能触发警告。
- 高频格式化（如导出万行报表）：提前缓存
CultureInfo实例，别每次 new - ASP.NET Core 中，考虑用
IStringLocalizer或ICurrencyFormatter抽象层，避免硬编码文化 ID - Unity 或 .NET Framework 4.x 环境要注意：部分文化 ID（如 "en-001"）可能不被支持，优先选标准缩写（"en-US"）
复杂点在于：货币格式不只是“加个符号”，它牵扯到数字分组、小数精度、负号位置、甚至 Unicode 双向文本顺序。一旦业务要出海或对接银行系统，这些细节全会冒出来——而且往往在上线后才报错。
