Super xing

nodejs是异步IO执行,所以我们将try/catch放置异步回调函数中,当出现一个异常时,try/catch操作只能捕获当次事件循环内的异常，我们通过try 拿到这个错误时错过了当前程序运行堆栈。(或者理解成，异步错误发生时在try catch块结束时候，所以当然不会被catch)之后 Node 会触发 uncaughtException事件,而在node.js原生的uncaughtExcep

指左边的画布写什么内容, 邮编的画布出现同样的内容在首先想到的解决方案是, 监听canvas move的事件, 进行画布同步, 但是同步后, 相对是有延时性的, 而且需要同时监听 mouse:down, 和mouse:move时间, 相对性能页不是那么优雅.监听 path:created 事件, path:created触发之后进行canvas 同步, 但是path:created 触发后,左边的

首页14kb规则是一项高性能HTML网页优化技巧：首页html大小不超过14kb。当用户打开网页时，收到的HTML的第一个TCP块为14kb。这是由于为平衡传输速度的TCP慢启动算法所导致。小HTML文件可帮助浏览器在接收到第一个块时开始解析。确切地说，在前14kb中包含足够的数据将使页面的渲染速度更快。当然如果启动了服务器端压缩如Nginx的gzip，应该是压缩后的14kb。以下来自http:/

workbox 是 GoogleChrome 团队推出的一套 Web App 静态资源本地存储的解决方案，该解决方案包含一些 Js 库和构建工具，在 Chrome Submit 2017 上首次隆重面世。而在 workbox 背后则是 Service Worker 和 Cache API 等技术和标准在驱动。在 Workebox 之前，GoogleChrome 团队较早时间推出过 sw-preca

场景复现：        页面打开不操作，前端项目代码更新重新部署后，页面不刷新，操作页面(点击打开弹窗、切换菜单等)，页面没有反应，控制台报错 Uncaught SyntaxError: Unexpected token <。这个问题偶现，只有在项目重新部署后会出现，页面刷新后就恢复正常问题分析：控制台报错可以看出，报错信息来自script，51.c

在同样的网络环境下，有两个同样能满足你的需求的网站，一个唰的一下就加载出来了，另一个白屏转圈转了半天内容才出来，如果让你选择，你会用哪一个？页面的性能问题是前端开发中一个重要环节，但一直以来我们没有比较好的手段，来检测页面的性能。直到W3C性能小组引入的新的API window.performance，目前IE9以上的浏览器都支持。它是一个浏览器中用于记录页面加载和解析过程中关键时间点的对象。放置

如果元素超出画布，就容易后面找不到了，所以这里要做一些规则 防止元素拖动超过画布，这里的理解比较简单，就是处理一些阀值情况，让元素不可以超出画布添加 object:moving 对象拖动事件this.canvas.on('object:moving', (e) => { const padding = 10; // 内容距离画布的空白宽度，主动设置 const obj = e

首先要安装koa-body用于解析请求数据      默认koa2-cli 自动生成的项目，采用的是koa-bodyparser， 这个sdk主要用开解析处理POST请求参数，但是这玩意有点缺陷，只能处理request payload 请求，如：我们上传图片，需要传入的是图片的file 二进制流，所以采用request payload 就产生了问题！所以这个时候，如果

关于Fabric的事情是一切都是基于对象的，大多数事情也是基于向量的。与原生画布不同，我们不能仅仅删除全局位图上的一些像素。我们在下面有整个对象模型，canvas输出是所有在canvas上呈现的那些对象的一个简单的循环。一. 我们的橡皮擦想要实现的是，擦出任意的一个部分，不能直接对对象实行删除，实现方案一： 以白色画笔为橡皮擦，在任何上面添加一个白色来覆盖当前的颜色，1. 如果白板有背景，2.如果

一、背景项目中遇到一个问题，同一个图片在 dom 节点中使用了 'img' 标签来加载，同时由于项目使用了 ThreeJS 3D 渲染引擎，在加载纹理时使用了 TextureLoader 来加载了同一张图片，而由于图片是在阿里云服务器上的，所以最后报出了如下错误，意思是在访问图片时出现了跨域问题：二、问题梳理2.1 关于图片的加载图片是来自于阿里云服务器的，和本地 localhos