可编辑表格：是指表格单元格是一个form表单元素，或者有可能会变成表单元素。
1、不可分页的表格，大数据渲染
当数据量足够大时，比如说1000条数据，页面渲染就会卡死，需要卡5s到10s，才能将数据渲染到页面，完全渲染出来后，页面的其他操作也是非卡顿，有明显的延迟感。
2、分页表格，用户大量新增数据，或复制、导入大量的数据
因前端分页，初始化时，以及完全渲染之后，页面都很流畅；但是当允许用户新增数据时，限制用户的新增数量也就不会有上述的问题，当不限制时，在完全渲染出来后，页面其他操作也会有明显的延迟感。
现需要对初次渲染卡顿，完全渲染卡顿两个角度，进行性能优化。
开发不定需求，需求能肯定最好，但是需求可能会从批量操作，导入等角度考虑，不要进行分页，那我们就只能进行性能优化
如果是单行编辑保存，或者是不可编辑的话，也不失为一个好的解决方案，
但是如果是编辑所有行之后，统一保存，可编辑表格，有必填项，运行了form的validate，就不能正常的进行表单校验，因为滚动出可视区域之后，form-item即被销毁，开发只能手写校验方法，且不同的业务功能，会有不同的校验规则，完全共用不了，增加组件的使用难度
当表格内容大于一定数量后，肯定是可以滚动的，滚动加载，表格滚动条的展示会有问题，需要使用虚拟滚动条，
滚动加载，比如先渲染20条数据，当用户滚动后，再渲染后面20条数据。初始化时，渲染速度很快，但是当用户滚动到一定程度，整个页面会渲染出大量的DOM，导致页面有明显的延迟感
点击加载，当可编辑时，该行允许用户编辑时，点击后，渲染该行的form表单，当用户点击其他行时，渲染其他行的form表单，销毁当前行的form表单，以控制页面展示dom的数量。但是会有必填字段没填，校验失败的字段，也销毁了，导致后面校验异常，更定位不到校验失败的字段。当然我们可以在校验失败时，也渲染form表单就不会有这个问题。
但是当数据很大时，依旧初次渲染卡顿，完全渲染卡顿，只能是属于提升性能的一个小手段吧
初始化时渲染所有的数据时，这一整个任务耗时严重，我们把这个任务拆分，渲染20条数据，500ms后渲染后面20条，直至所有数据渲染完毕，可以解决初始化渲染卡顿的问题，但是会有完全渲染后卡顿的问题
content-visibility: auto，跳过屏幕外的内容渲染，解决完全渲染后卡顿的问题
各个方案均有利弊，没有完美的解决方案，需要具体的问题具体分析；
多个技术聚合使用，采长补短，达到符合自身的需求；
现说一下我的优化套餐
点击加载 + 任务切片 + 动态渲染，只提交被修改的数据，只校验被修改的数据保存校验时，可以正常校验，并定位到校验失败的字段
缺点：
2024/01/08持续维护中…