写在前面，关于签名的应用场景 除了我们后端经常使用的接口签名来校验数据这些常见的场景，对于数据安全性要求比较严格的业务来说，大部分落库的核心数据 也都需要签名，为啥? 因为怕数据库的数据被篡改数据或者被攻击了，通过数据库签名就能保证每一行数据的可靠安全性

1、常见的签名算法

老生常谈，我就不一一举例了

• MD5
• AES
• RSA

2、步入正题

最近开发的某系统的一个订单的赔付的功能，那么赔付订单的流水表数据就很关键了，必须加签名- -什么？有bug？不存在的！

bug 背景：
签名检验失败：db sign check error old: 39a22a50f78b076497aa703e2677cf0e but new is: 45caf3b7b67508675c87c324c74240f8
不难看出 数据的签名校验失败了 是不是有人动过？（眼睛睁大的像个铜铃）：

相信眼尖的盆友立马发现 这个时间为啥不一致啊
生成签名的时候 日志显示秒位是15，怎么到了数据库就变成16了？最后查询记录再校验签名肯定不对啊！
经过测试发现居然会进位：条件if time.millisecond > 500 就会发生进位 比如15.873 最后就变成16了 - -

3、如何规避这个进位问题

func timeTest() {defer EnterExitFunc()()fmt.Println(int(time.Now().Weekday()))now := time.Now()fmt.Printf("now: %v\n", now)dateStr := now.Format("2006-01-02 15:04:05")fmt.Println(dateStr)date, _ := time.ParseInLocation("2006-01-02 15:04:05", dateStr, now.Location())fmt.Printf("after: %v\n", date)fmt.Println(date.Format("2006-01-02 15:04:05"))
}// output打印如下：
now: 2023-08-10 15:11:00.40468 +0800 CST m=+0.000770626
2023-08-10 15:11:00
after: 2023-08-10 15:11:00 +0800 CST
2023-08-10 15:11:00

仔细看发现经常转换之后 时间的微秒位没有了 这样就规避了微秒进位问题
当然还有另外一个办法 从建表语句开始 定义字段的时候使用 datetime(6) 或 timestamp(6)