我们的认知:
当我们去判断前端Form表单有没有变化的时候，通常会采用什么方法呢？相信框架是我们的本能，比如Angular，React。。。等前端框架都自带判断方法，那么这样的方法是不是100%可信呢？
故事是这样的：
我们的产品里，可以理解有一个个大表单。表单里面的内容可以分为A部分和B部分。通过判断表单里面值有变更的字段是属于A部分还是B部分来进行不同的业务逻辑处理。
在测试中，我们发现在其实只动了B部分的字段，结果却跑到了A部分被修改的业务流程里，what are you弄啥嘞？莫慌莫慌，我们来看看发生了什么：
1. 打开developer tool bar看一下请求是啥，咦，前端状态发错了，认为A变了，有理有据有截图，直接去找了前端
2. 在等待开发调查的过程中顺手去chrome上测了一把，然后发现:what? Chrome竟然没有这个问题，请求的参数都是对的，就是这么神奇？这样的bug还分浏览器，吓到了我的三观。
赶紧把这一消息告知前端说是IE的问题，前端着手调查，中间差不多等了有好几个好几千秒。前端说找到问题了！ 真棒~~
问题的原因：
QA同学：我没有修改A的内容，前端页面也不允许我修改，只是改了B，为什么我提交的时候却影响了A呢？
开发同学：是的 ，你没有动A里面的字段，但是IE替你动了。
QA同学：纳尼？？？？
开发同学：ie会在API返回的数字上加上.0，比如API返回”45“，ie给你”45.0"，而前端渲染的时候删掉了这个".0"，所以当我们在提交表单的时候，我们的对比机制发现form表单数字的字段都发生了修改，因为A部分的优先级更高，因为你修改了这个字段值，所以就会回到A阶段。
QA同学：这个问题什么时候发生的？为什么以前没有问题？
开发同学：????
在风中凌乱。。。。
解决方案：
开发同学苦心调研，告诉我们说Angular判断form表单有没有变化有两种姿势，第一个是值有没有变化(默认姿势)，第二个是这个字段有没有被touch。我们自然而然的使用了第一种方式，结果IE在这块给我们挖了个坑。所以为了解决这个问题，我们的校验规则会把两个方式结合起来，就是说既被touch到值又发生变化的时候我们才认为字段有修改。
。。。。。。。。。。。。。中间省略掉几个不成熟的方案。。。。。。。。。。。。。。。
学习和收获：
IE可不是只有样式问题，它让你挂掉的姿势有一万种，有待我们继续探索。而前端框架丰富多彩，自带的很多方法也非常的高效好用。只是在愉快的写代码的过程中，我们需要思考一些细节，谨防各种浏览器挖坑。
