背景
有一个表格，其中有部分字段可编辑，可编辑的字段不固定，由业务条件动态计算出来，可编辑字段可能是文本输入框、数字输入框、选择器等
表格结构
表格上方是按钮区域，按钮区域初始展示Edit按钮，此时表格所有字段处于正常展示态，点击Edit，进入表格编辑态，表格中可编辑字段会变成输入框、选择器等，按钮区域变成Cancel和Confirm两个按钮，分别代表取消编辑和确认编辑两种功能
关于表格： 前两个字段固定展示在左侧(sticky)，最后一个字段固定展示在最右侧(sticky)，这三个字段确定不可编辑，不随其它字段一起滚动
目标功能
当点击Edit按钮，第一个可编辑字段自动滚动至可视区域，紧贴在第二个sticky字段的后面
实现
这是一个目标节点自动滚入视区的功能，自然而然想到了scrollIntoView方法
- 首先遍历columns获得第一个可编辑的字段，给目标字段（表头和表格内容）加特殊类名标识first-edit-col
- 当点击Edit按钮时，延时2s(等待重渲染完毕)获取类名为first-edit-col的所有节点，对这些节点调用scrollIntoView
以为这就可以了吗？No，问题出现了！ 当点击Edit按钮，第一个可编辑字段并没有如预期那样滚入视区，仅靠在第二个sticky字段的右侧，而是正好在视区右侧，差一点儿就进入视区了，唉。除此之外，，，当手动左右滑动表格时，表头和表格内容错位了！！，将表格滚动至最右侧，表头和表格内容又恢复对齐，再来回滚动也不会有问题了。
而如果在表格错位后，先滑动看左侧字段，会发现根本滑动不了，按理说第一个可编辑字段左侧的字段在滑动后可以正常出现才对，但现在这些节点直接“丢了”
这个问题看上去是表格有动态计算逻辑导致的，scrollIntoView打乱了计算逻辑
一开始我以为是表格中sticky的字段影响了滚动，所以首先尝试把所有sticky功能都去掉，事实证明没有起作用，还是错位
然后猜想表格自定义了scroll功能（因为我发现表格的滚动条是自定义的），scroll计算逻辑和scrollIntoView冲突了，绝望之际，突然发现表格设定了虚拟滚动！！
没错，罪魁祸首就是虚拟滚动导致的，因为这个表格已知确定数据量很小，所以果断去掉了虚拟滚动，结果，错位如期恢复
