① 前端 js（java - double 类型 ）数字精度详解
在数字计算中，我们常会遇到一些诡异的现象，尤其是在前端JavaScript和后端Java的double类型数字计算时。这往往源于两种语言对数字的存储方式——使用IEEE 754标准的双精度64位浮点数。这就意味着我们常规的十进制计算在转换成二进制后进行计算，再转回十进制时，可能会出现精度丢失的现象。接下来，我们将探讨数字从十进制转换为二进制的过程，以及为什么在进行十进制与二进制之间的转换时会丢失精度。
首先，我们来看整数的二进制转换。以数字17为例，计算过程如下：17除以2得到商8余1；8除以2得到商4余0；以此类推，直到商为1。将得到的余数从低位到高位排列，得到二进制数10001。如果数字为100，计算过程类似，最终得到的二进制数为1100100。
对于整数二进制转换为十进制的过程，我们只需将二进制数从右到左进行2的幂次方运算，然后将结果相加。例如，二进制数0010011转换为十进制，逆序排列后得到0010011，计算过程为：0*2^0 + 0*2^0 + 1*2^2 + 0*2^0 + 0*2^0 + 1*2^5 + 1*2^6 = 100。
接着，我们讨论小数的转换。小数转换为二进制时，将小数乘以2，取整数部分作为二进制表示的第1位，将小数部分继续乘以2，得到的整数部分作为二进制表示的第2位，以此类推。如果小数部分出现循环，无法停止，那么在编程语言中表示小数时就可能出现误差。以0.1为例，计算过程如下：0.1*2得到0.2，取整得到0；0.2*2得到0.4，取整得到0；继续计算直至小数部分为0，最终得到二进制数0001001001001001……，如果是2.1，则为10.0001001001001……
为什么数字转换会出现不精确的情况呢？这与JavaScript中数字的存储方式有关。JavaScript中的数字采用IEEE 754标准的双精度64位浮点数来存储，表示格式为：(s) * (m) * (2 ^ e)，其中s表示符号位，m表示尾数，占52位，e表示指数，占11位。根据ECMAScript 5规范，e的范围是[-1074, 971]，最大表示值为1 * (2^53 - 1) * (2^971) = 1.7976931348623157e+308，最小表示值为1 * 1 * (2 ^ -1074) = 5e-324。因此，JavaScript能够表示的最大整数是2^53 - 1，即9007199254740991，最小的正数为5e-324，最大值为1.7976931348623157e+308。
在进行十进制与二进制之间的转换时，由于数值的存储和表示方式的限制，可能会导致精度丢失。例如，当我们进行十进制的0.1和0.2相加时，最终结果可能会是0.30000000000000004，这是因为浮点数在转换和计算过程中可能会产生极小的误差。
解决这个问题的方法之一是将数字转换为字符串进行处理，这样可以避免浮点数的精度问题。在实际应用中，后端处理数据时，最好将数字转换为字符串格式传递给前端，以避免精度丢失。对于在JavaScript内部进行安全范围内的计算，保持精度，可以使用库类如bignumber，提供高精度的数学计算功能。
总结来说，数字转换过程中出现不精确的现象，主要源于计算机对数字的存储方式以及计算方式的限制。理解并掌握数字转换的基本原理和解决方法，对于提升编程能力和开发质量至关重要。
② 挖一挖：PostgreSQL Java里的double类型存储到varchar精度丢失问题
前言
在使用Java JDBC将double类型数据插入到PostgreSQL数据库的表中时，发现不同版本的PostgreSQL（11与12及后续版本）插入的数据结果不一致。本文将探讨此问题的可能原因和解决方法。
分析
在Java代码中，使用的是相同的JDBC驱动。问题可能出在驱动层根据服务器端不同版本发送的数据不同，或服务器端对于客户端传入的数据处理方式不同。为了寻找答案，我们查看了SQL日志。
通过修改`postgresql.conf`文件，将`log_statement`设置为`all`，我们得以查看详细的SQL日志。结果表明，在服务器端绑定参数值时，数据在PG11与PG12版本中发生了变化。进一步，检查JDBC客户端驱动层日志，发现了关键信息。
在PG12的日志中，我们注意到当`extra_float_digits`参数设置为3时，数据出现精度损失。而在PG11中，相同参数设置下，数据保留了较高的精度。这揭示了问题的根源在于服务器端处理浮点数的方式在不同版本间存在差异。
总结与模拟重现
综合分析，驱动层发送给服务器端的指令在不同PostgreSQL版本间并未发生变化，问题在于服务器端对于`extra_float_digits`参数值为3时，处理浮点数转为`float8`（double precision）的机制不同。在PG11版本中，数据在转换过程中保留了较高的精度，而在PG12及后续版本中，则出现了精度损失。
了解`extra_float_digits`参数用于控制浮点数值的显示位数，对于理解问题的产生至关重要。该参数调整用于文本输出浮点值的位数，不同设置影响了输出的精度和易读性。通过对比不同版本的处理方式，我们确认了问题原因在于服务器端在处理浮点数时的精度控制不同。
总结，通过对比分析两端的日志信息，可以深入挖掘并解决此类问题。同时，通过简单的SQL片段可以重现问题，有助于进一步验证和理解问题的根源。
参考资源
本文基于以下资源撰写：
enterprisedb.com/blog/j...
jdbc.postgresql.org/doc...
postgresqlco.nf/doc/zh/...