必要解释：最好看完。。省流版的话，toDataURL 的 multiplier参数不要设置超过500；

情景：在做某些功能的时候涉及到图形的预览，预览的时候是导出为40*40 像素的图片，当碰到某些图形非常小的时候，例如该图形是0.01宽/0.01高，那么如果想要得到该图形40*40大小的图片则需要放大非常大的倍数 multiplier，从而导致 toDataURL 一个函数就需要执行1秒(根据放大倍数而定)，且放大的倍数 multiplier 有一个临界值，当multiplier的值超过xxx时，multiplier每提高一段倍数，所需的时间更长。例如multiplier800是1秒，multiplier1200是2秒 （当时情况已经忘了，所以只是打个比方，感兴趣的自己测下就知道了）。。

吐槽：当时解决大量图形的性能瓶颈，解决完虚拟化列表后，自测时还是发现某些情况下（某些素材）加载时、操作时有性能问题，当时找了半天最后才发现是 toDataURL 导致的性能问题；

---

解决方案：

宽||高超过40的就是缩小了，不存在性能问题；
0.01*0.01的图形放大至40的时候，40/0.01就会得到4000的倍率，而且这么这么小的图形即使放大，也看不清，故而采取措施为将该图形不进行图片提取，反正拿到图片你也看不见这图形，不如不拿就完事了。。

本文其实就是讲解思路和问题点所在，代码案例写不写无所谓，没啥复杂的，但也分享下自己案例的相关片段；

          val.clone(async (newShape: fabric.Object) => {const options = {strokeWidth: 1,} as any;if (newShape.stroke) {options.stroke =newShape.processMode === ProcessMode.cut? newShape.originStrokeForCut: newShape.originStroke;}const w = newShape.width && 30 / (newShape.width * (newShape.scaleX as number));const h = newShape.height && 30 / (newShape.height * (newShape.scaleY as number));const multiplier = Math.min((w || h) as number, (h || w) as number);e.base64 = '';if (multiplier < 500) {multiplier < 1 && (options.strokeWidth = (1 / multiplier) * 1.5);newShape.set(options);e.base64 = newShape.toDataURL({multiplier,});}});