这里给出一种轻松愉快的解决方案： console.log(JSON.stringify(data, null, 2)) 即可。

Promise 的设计就是一个状态机，pending 到 resolve / reject 的状态变换是单向且唯一的，没有所谓的 cancel 状态。cancel 的加入会带来更多的状态问题，并不适合 Promise 这一模式来处理（这类场景下，RxJS 这类 FRP 的方案应该更为适合）。

最简单粗暴和方便的做法是： 在需要调试的代码行前添加一句 debugger 形如 {代码...} 这样不论是异步还是同步，都可以非常轻松地在相应位置打开调试器来进行调试了。 （论调试策略，前端有 php 狗撑起来的 console.log 党和 java 狗撑起来的断点调试党，我站前一个）。

从 JS 的角度看，执行同步方法时，整个应用会阻塞在其中，这时即便是 setTimeout 异步触发的回调，也要在同步方法执行完成后的 Event Loop 中才能执行，因此不能够在同步方法中检查自身的执行时间并 Kill 自身。

这说明你所请求的 API 与你的页面并不在同一个域下，如果该 API 没有设置 Access-Control-Allow-Origin 字段，那么说明它并非一个支持跨域访问的 API 接口。页面编写 Fetch 逻辑时，不论请求头如何定制，也会被浏览器拦截（fetch 前，浏览器会发起一个 preflight 的 ...

…页面内容不是应该写在 body 里才会显示吗？

首先，JS 人肉维护 DOM 的【过程式编程】在可维护性上是劣于模板风格的【声明式编程】的。考虑一行简单的 <div>xxx</div> 和一大坨 document.createElement('div')...，它们在可维护性上有天壤之别。

（如果看过 JSONP 库的源码就知道，常见的实现代码其实就是 document.createElement('script') 生成一个 script 标签，然后插 body 里而已。在这里根本没有设置请求格式的余地）。

data 中的内容只会在 created 钩子触发前初始化一次，类似于你直接写 const data = { foo: 123 } 这样，这时属性的值是纯粹的字面量，而不是回答者所谓的【缓存】(没有 Cache Miss 哪来的缓存？)。JS 字面量赋值后显然不会自动更新。最简单的例子：

就地去重的思路很简单 建立一个以每个数组元素为 key 的 hash 对象 每个元素通过 hash 判断其是否已经存在与数组中 如存在，将该元素删除 遍历完成后，移动数组元素，填补空位 由于移动数组元素是一个高耗操作（例如 N 长数组被均匀挖掉 N/2 个空，那么这时由后往前...

一个简单的示例如下（这很接近我司的一道前端笔试题，通过的同学基本可以随手写出来）： {代码...}

具体到项目结构上，main.js 是整个项目的入口（在此除导入 App.vue 的 UI 外，还导入 router / vuex / axios 等辅助库与插件），App.vue 是 UI 逻辑的入口，而 index.html 则通过 script 标签来引入 main.js，将脚本执行的内容注入 #app 中。

算法应该并不难： 将 canvas 区域区分为形如 100x100 的网格 每次鼠标事件，判断鼠标位于哪个网格内 将该网格直接 fillRect 绘制为网格内的平均颜色（网格内全部点的 rgb 取平均，或直接取网格内某一点颜色） 这就实现了叠加马赛克的基本算法。

script 标签使得模板内容不会显示在页面上。从而在使用 jQuery 渲染数据时，就不需要 HTML 字符串拼接，而只要直接取出模板中的 HTML 文本，用 JS 做正则替换即可：

很明显这种【逻辑上功能完全内聚】的一块区域，不管是 React 还是 Vue 都可以放在同一个 UI 组件中。题主所给出的细化组件切分示意图，基本完全就是 DOM 的嵌套嘛。照这么搞，干嘛不一层 DOM 套一个组件呢？

这可以通过一个额外的插件配置解决： [链接]

很好的问题。简单的原理理解是：JSX 的一对封闭标签，会转译为一个 createElement 函数。如下的代码转译后，实际上会变成两个并排的函数。

或者，可以在 package.json 的 npm script 中编写 "gulp": "gulp xxx"，从而使用 npm run gulp 来运行项目内安装的 gulp