C# Double.ToString()在NUnit与应用程序中行为不一致原因咨询

该运行差异与NUnit框架本身无关，是两个运行环境配置不一致，叠加当前实现逻辑的固有缺陷共同导致，具体可以拆为两部分：

1. 双精度浮点数解析、格式化的环境配置差异 #

double为64位双精度浮点数，仅能保证15~17位十进制有效数字的存储精度，传入的输入值0.000000000000000000003402823499999999有效位数远超出该上限，解析过程本身只能得到近似值，不存在绝对精确的转换结果。
观测到的转换值差异，通常由以下两类配置不一致触发：

• 进程架构不一致：若NUnit测试进程运行在32位模式（例如项目勾选了「优先32位」编译选项），实际应用运行在64位模式，x86与x64架构下JIT的浮点运算优化策略、调用的CPU浮点指令精度存在区别，解析超精度小数值时得到的近似结果会出现末尾位偏差。
• 运行时版本不一致：若测试项目与实际应用采用不同版本的.NET实现（例如一个为.NET Framework 4.x，一个为.NET 6+），不同版本基础类库中Double.TryParse、Double.ToString的实现逻辑存在调整，默认输出的有效数字位数也有区别：老版本.NET Framework默认对double格式化输出15位有效数字，新版本最多输出17位有效数字，这也是两个环境下科学计数法表示的小数部分长度不一致的直接原因。

2. 现有拆分逻辑存在设计缺陷 #

通过convertedValue.ToString(CultureInfo.InvariantCulture)后按.拆分的逻辑，完全依赖double默认格式化的输出结果，本身不具备可靠性：
当double的绝对值过小（小于1e-15左右）或过大时，默认格式化会自动切换为科学计数法表示，此时字符串中的.并非原数整数部分与小数部分的分隔符，拆分出的结果会携带科学计数法的E-xx后缀，无论在哪个环境运行，该拆分结果都不符合整数、小数部分拆分的预期。

如果需要可靠拆分转换结果的整数和小数部分，不要依赖默认ToString的输出行为：

• 若输入值范围在decimal支持区间内，优先使用decimal类型做转换，decimal不会自动使用科学计数法格式化，精度也能满足常规数值计算需求，拆分结果更稳定。
• 若必须使用double类型，格式化时需手动指定格式字符串，强制禁用科学计数法、保留足够小数位，例如使用convertedValue.ToString("0.#############################", CultureInfo.InvariantCulture)拿到定点表示的字符串后再做拆分。

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