1、问题

最近接手一个商城运单号模块，接手后发现有部分运单号返回给前端是按照科学计数法的方式返回，如：8.0497183772403904E+17，后查库发现这些运单号在excel导入的时候就是按照科学计数法导入，没做任何处理。

按照科学计数法的形式返回给用户运单号，这样太不友好了，简直就是bug，所以需要进行转换处理后再返回给用户。

2、问题修复

面向谷歌编程，找到了以下方法进行转换：

第一种：

oldNum := float64(8.0497183772403904E+17)

newNum := big.NewRat(1, 1)

newNum.SetFloat64(oldNum)

fmt.Println(newNum.FloatString(0))

结果：

804758523075821952

第二种：

varnewNum float64

numStr := "8.04758523075822e+17"_, err := fmt.Sscanf(numStr, "%e", &newNum)if err !=nil {

log.Errorf("fmt.Sscanf error, numStr:%s, err:%v", numStr, err)return}

num := fmt.Sprintf("%.f", newNum)

fmt.Println(num)

结果：

804758523075821952

以上两种转出来的都会精度有所丢失，具体原因未知，现在还未去深究，有知道的朋友希望可以评论回复解答一下，谢谢。

第三种：

以上两种都存在丢失的问题，起初是不知道的，后面通过java进行转换了才发现真的丢失了java代码如下：

BigDecimal bd = new BigDecimal("8.04758523075822e+17");

System.out.println(bd.toPlainString());

结果：

804758523075822000

java既然可以通过BigDecimal进行转换，那golang肯定也可以(很不幸我使用的是go1.11.2没找到decimal的相关包支持，只能面向github编程了)，在github中找到了一个较多人使用的包 github.com/shopspring/decimal

使用代码如下：

//先安装包 go get github.com/shopspring/decimal

numStr := "8.04758523075822e+17"decimalNum, err := decimal.NewFromString(numStr)if err !=nil {

log.Errorf("decimal.NewFromString error, numStr:%s, err:%v", numStr, err)return}

fmt.Println(decimalNum.String())

结果：

804758523075822000

3、总结

在进行科学计数法的数字转string数字的时候，最好还是使用第三种方法，这样不会精度丢失的情况。当然导入excel的业务上要做好判断处理，若是纯数字运单号入库就应该是纯数字而不是科学计数法的形式。

package main

import ("encoding/json"

"fmt"

"github.com/shopspring/decimal"

"strconv"

//"github.com/shopspring/decimal"

)

type abcstruct{

Goods_id float64 `json:"goods_id"`

Goods_namestring `json:"goods_name"`

}

func main(){

a := `{"goods_id":1.1572417766286e+18,"goods_name":"LM358"}`

aaa := &abc{}

err := json.Unmarshal([]byte(a),aaa)if err !=nil{

fmt.Println(err)

}

fmt.Println(aaa)

decimalNum, err :=decimal.NewFromString(strconv.FormatFloat(aaa.Goods_id, 'e', -1, 64))if err !=nil {return}

fmt.Println(decimalNum.String())

}

D:\gocode1.14\go-micro-code\gjj>go run main.go&{1.1572417766286e+18LM358}1157241776628600000