故事起因：多人同时操作一个工作单据，保存时间有先后，后保存的数据覆盖了前面保存的数据。网上找到文章都是讲并发处理的原理，没人提到数据丢失后的处理。
这是个真实的案例，对于数据量很少的单据可以随时丢弃脏数据，但是如果是软件管理系统里含有大量数据的表单，直接丢弃就不好了。见下图
举例说明，我们在给一个供应链客户做的一张工作单，里面涉及的服务同时有两种（海运和陆运），其中：
1. 安排海运工作的文员A记录海运的信息;
2. 安排陆运工作的文员B记录陆运的信息;
但是非常不幸的是，两人几乎在同一时间段打开了同一张工作单据，分别录入自己负责的信息，然后保存（A在前，B在后），之后A在查看单据的时候就叫起来了：天啦，我辛辛苦苦的数据不见了！
聪明的你一定想到了，文员B在打开工作单输入“陆运”信息时，“海运”信息全是空的，最后保存时把A的数据给覆盖了（导致A的“海运”数据不见了），原理图如下：
你也许会嗤之以鼻：切，不就是并发没处理好，导致数据覆盖么。这点小问题，秒秒钟搞定的事。
这种典型的数据并发操作问题，技术上的解决方案也是一搜一大把，归结为两种：
1. 悲观锁：任何一个人打开编辑此单据，标记为锁住，其它人等不得打开编辑，直至它被解锁。
2. 乐观锁：任何人都可以打开单据，可以编辑，保存时通过版本号校验，不通过者视为脏数据，提示数据已更新，不能保存。
鉴于我们的项目是基于WEB的，第一种直接否掉了，第二种实现起来，代码也不难。
我把以上的技术一分析，给她们回复：“我们有了解决方案，谁先保存谁赢，后面才保存的同学，系统说你来晚了，不好意思，你的数据要重新录咯”。So easy，小问题嘛，很容易解决滴。
-------------------- 剧情反转的分割线------------------
可没料到，文员A跳起来对我们说：“ 你们的系统就是狗屎！我花了半个小时辛辛苦苦输入的几十个数据，因为我保存晚了，说没了就没了，你TM在逗我？！”。
咦？我感觉到被妥妥的打脸了，想想人家说得很有道理。数据录入多的人，需要的时间也更长，保存的时间当然会靠后，按我的处理方法，吃亏的是最辛苦的人。原理图如下：
好吧，我道歉，我再想想办法。
And， 作为一个伸手党，我开始在百度上找相关的处理方法，尝试了无数关键字去查找，讲数据库并发冲突原理的有一堆文章，可是就是没人考虑过数据丢失的人的感受，没有人讲如何处理脏数据，没有人！
你们这些宅男IT狗（包括我啊），你们不知道做运输公司、货代、报关企业里接单录单的妹子是多么需要有人多为她们想想，如何才能高效录入单据和节约时间的么？
在和组里小伙伴经过激烈的讨论后，最终采取的方案是：
把用户输入的临时数据在刷新前先保存起来，刷新后在页面提示其可以恢复之前的未保存的数据，有冲突的数据做提示。
技术实现
1. 如果后台提示是版本号不一致的问题，将用户所填的数据保存到浏览器 localstorage；
2. 刷新页面后，判断当前单据是否有缓存数据，如果有，则提示“你有未保存数据，是否恢复？”；
3. 选择“是”， 恢复数据到页面中，并做冲突提示，从localstorage删除数据缓存；
4. 选择“否”，不恢复数据，从localstorage删除数据缓存；
根据此做出方案，录单文员那边表示这个功能棒棒哒。哟吼，问题就此解决咯。文员和IT狗又可以愉快的玩耍了，么么哒！
结论
即将丢失的脏数据也许花费了用户大量的时间去录入，我觉得这个脏数据缓存处理非常重要和必要，看情况多想想就会提供多些价值。IT开发人者要么是觉得过于简单没在意，要么是开发者没有进一步想这个问题，这是非常不好的。我认为每个人的时间和效率都是无比珍贵的，希望同学们不要浪费你的用户的时间。
既然如何处理这个脏数据问题在网上没人提到（或是我没找到），那么我就把它记录下来，以助后人。
学海无涯，在学习的道路上，你并不孤单，希望本文可以帮助到相关的人，我是物流IT人，刘宇，谢谢，再见。