本文主要是介绍线上业务修改时间小于创建时间问题回顾，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
问题描述
某一天偶然发现生产库某个业务存在修改时间modify_at小于创建时间create_at的数据：
开发环境当时没有，后来也有了：
按理modify_at不可能比create_at小。
开始排查
首选确定了数据是用户录入的，不是导入的，另外没有改过数据，找到接口后，代码如是：
代码中通过id判断是不是新数据，进而区别设置创建时间和修改时间，不会有问题。当时比较匪夷所思，不知道这样的数据是怎么来的，后来测试同事复现了，发现前端在新增有时会传入modify_at。
确定问题原因
新增时前端有时会传create_at和modify_at，传create_at没关系，服务端会重置，传modify_at就可能出现modify_at<create_at，因为新增时没对modifyAt重置，导致用了前端传的modify_at。如果再编辑这条数据，modfiyAt会恢复正常，因为服务端会重置。
讨论
为什么前端会传createAt和modifyAt，因为把这个两个字段暴露给了前端，是否不应该在VO中暴露createAt和modifyAt给前端？当时是回查的时候用于显示，不过前端确实没有用到。
另外验证了`create_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `modify_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间' 的设置，表名如果提交到数据库服务器的数据没有创建时间，用数据库服务器的时间，如果没有更新时间，也用数据库服务器的时间，如果执行了update，默认将更新时间更新为此刻数据库服务器时间。把本地电脑时间改掉，观察create_at和modify_at用的是什么时间，结果表明如果最后提交到数据库的数据有时间，会用数据中的时间，这个时间可能来自本地电脑，可能是前端传了。服务端传的话是可以的，前端传就有问题了。所以归根结底，前端不应该传create_at和modify_at。
最后一点，接口录入上也要规范，不应该把createAt和modifyAt写出来，当时报酬新增接口是没有写的，前端同事没有严格按照接口说明联调。
你们对这个问题怎么看呢，欢迎留言讨论哈。
这篇关于线上业务修改时间小于创建时间问题回顾的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
