使用InvariantCulture时.NET ToString科学计数法负号不一致问题

针对你遇到的问题：本地与客户环境同样为Windows系统、激活en-SV文化，且明确指定CultureInfo.InvariantCulture执行double.ToString("E16")转换，但负号分别输出U+002D（连字符）和U+2212（数学负号），且已排除文化设置、NLS/ICU开关的影响，以下是其他可能的影响因素：

• .NET运行时小版本差异：即使双方都基于.NET 6，不同的补丁版本（如6.0.10 vs 6.0.20）可能内嵌了不同版本的ICU组件，或者包含了全球化相关的修复/变更，导致格式化行为不一致。VS2022默认使用的.NET SDK版本通常比VS2019更高，编译后依赖的运行时组件可能存在差异。
• 全局文化配置或第三方钩子：检查是否有代码通过CultureInfo.DefaultThreadCurrentCulture/CultureInfo.DefaultThreadCurrentUICulture全局修改了线程文化，或者引入了第三方全球化相关库，这类代码可能拦截格式化逻辑，即使显式指定InvariantCulture也会被影响。
• 程序集绑定重定向问题：如果项目中存在对System.Globalization或相关核心程序集的绑定重定向配置，可能导致运行时加载了非预期版本的组件，进而改变格式化行为。
• Windows区域高级自定义设置：虽然表面是en-SV文化，但客户系统可能在区域设置的「高级设置」中自定义了负号符号（替换为U+2212），这类自定义配置可能不会通过常规的CultureInfo属性暴露，需要直接检查系统的区域格式自定义项。
• 编译工具链与发布选项差异：VS2022使用的MSBuild和.NET SDK版本更高，若发布时启用了Native AOT、Trim（裁剪）等优化选项，可能会对全球化组件的行为产生影响，比如裁剪了部分默认文化资源或改变了格式化逻辑的实现方式。
• 其他全球化相关环境变量：除DOTNET_SYSTEM_GLOBALIZATION_USENLS外，DOTNET_SYSTEM_GLOBALIZATION_PREDEFINED_CULTURES_ONLY、DOTNET_SYSTEM_GLOBALIZATION_INVARIANT等环境变量若被客户环境意外设置，可能导致InvariantCulture的行为偏离预期。

内容的提问来源于stack exchange，提问作者Helena