前言Nodejs现在几乎是每个前端必备的了，无论你玩不玩后端服务开发，在前端的构建上也是必备的软件了。这里总结下自己在windows系统下用这么久Nodejs的各种优化设置，让新人少走弯路，新装nodejs的可以跟着设置，一次安装设置一劳永逸。 git安装sudo apt-get install git nvm安装 nodejs这里推荐用nvm安装Nodejs，因为 有些npm包并不兼容所有版本的nodejs（例如早期的node-sass） 有些软件也指定了具体版本的nodejs才可以运行(例如: ghost cms, strapi cms)用nvm可以自由切换各个nodejs版本最是个不过了 nvm 安装仓库：coreybutler/nvm-windows链接：Install nvm-windows 安装完后先设置node的安装源为国内taobao，这样安装nodejs才快nvm node_mirror https://npm.taobao.org/mirrors/node/ nodejs安装然后就可以安装各个版本的nodejs了 已安装的版本nvm ls 安装指定版本nodejsnvm install [version] 推荐stable 切换版本`nvm use [version] nodejs设置修改全局包的安装位置相信很多人的电脑跟我一样，系统盘是200G以内的固态硬盘，空间有限。而npm全局又默认安装在系统盘上，前期倒没什么事，但是后来发现用久后，全局包变多变大了，系统盘本来就有限，然后系统盘可用空间越来越少，所以修改全局安装包安装位置才好一劳永逸。 // 设置全局包的安装位置，路径自己修改成自己要安装的位置 npm config set prefix "D:\nodejs\global" // 设置npm cache位置 npm config set cache "D:\nodejs\cache"然后要添加个系统变量Path项，地址填全局地址 然后在添加个NODE_PATH系统变量，值为全局npm路径 + node_modules 用nrm 管理npm源当你想切换npm源的时候，你是不是就要打开百度，去查找源的地址，然后设置，不然谁会没事记各种源的地址呢。 所以这里推荐用nrm来管npm的源 安装npm install nrm -g所有源nrm ls使用源nrm use [name] 这里推荐用taobao源，比较快当你需要发布npm包的时候记得切换回npm官方源 设置npm个别软件源虽然上面我们设置了npm的源，但有些npm包需要去下载一些软件，而这些软件的下载地址都是国外比较慢，我们用到时需要去指定更改源。 例如node-sass electron phantomjs npm config set electron_mirror https://npm.taobao.org/mirrors/electron/ npm config set sass_binary_site https://npm.taobao.org/mirrors/node-sass/ npm config set phantomjs_cdnurl https://npm.taobao.org/mirrors/phantomjs/以上的一些配置都会保存写入到C:\Users\当前用户\.npmrc .npmrc就是npm的全局配置文件 你也可以直接打开.npmrc来修改配置，不用一条条命令输入： registry=https://registry.npm.taobao.org/ electron_mirror=https://npm.taobao.org/mirrors/electron/ sass_binary_site=https://npm.taobao.org/mirrors/node-sass/ phantomjs_cdnurl=https://npm.taobao.org/mirrors/phantomjs/node-gyp`安装node-gyp，是由于node程序中需要调用一些其他语言编写的 工具 甚至是dll，需要先编译一下，否则就会有跨平台的问题，例如在windows上运行的软件copy到mac上就不能用了，但是如果源码支持，编译一下，在mac上还是可以用的。node-gyp在较新的Node版本中都是自带的（平台相关），用来编译原生C++模块。 npm install node-gyp -g windows-build-tools安装Windows的构建工具 npm install --global windows-build-tools 为啥要一键安装呢，安装的是啥呢？ 　　解释：　1、python(v2.7 ，3.x不支持); 　　　　　　2、visual C++ Build Tools,或者 （vs2015以上（包含15)) 　　　　　　3、.net framework 4.5.1 就是安装的这三个东西，安装时间有点长，别着急，慢慢等~

GROUP BY 查询默认是去每个分组第一条很多时候我们需要获取每个分组的最后一条，例如查当前用户于其他用户的聊天记录的最后一条。 原始sql: SELECT * FROM table GROUP BY type ORDER BY createdAt DESC这里的ORDER BY是不生效的，因为GROUP BY 的执行会先于 ORDER BY 于是我们可以先排序后再来GROUP BY： SELECT * FROM ( SELECT * FROM table ORDER BY createdAt DESC ) as result GROUP BY result.type大功告成！但是在某些mysql版本group by虽然不是拿了第一条，但也不是最后一条，奇了怪了。排查下，排序的查询是没问题，GROUP BY 后就出问题了。后来百度以一段时间啊，好像有些兼容性，排序查询的时间要加上LIMIT就可以了 完整的正确写法: SELECT * FROM ( SELECT * FROM table ORDER BY createdAt DESC LIMIT 9999 ) as result GROUP BY result.typeNices!

背景为了生活更美好，最近开始学起了理财。穷人家的孩子，从小到大没人告诉过你理财的重要性，自然也就没那习惯了，后来自己出来赚钱了。自然开心啊，自己的钱次怎么花就怎么花。之前喝瓶可乐都要问老爸老妈，现在直接一箱箱买，想喝就喝，快哉快哉。长期这么自由自在真的很爽，可存款却永远在原地踏步，不见增长。眼看身边的人都买车买楼了，而自己还一无所有。可见凡事都有代价的。总结下原因就是不会理财、大花、月光族等等。于是痛下决心开始理财，控制自己的消费。第一步就当然是记账啦。记账可以知道自己每个月的消费、收入，清晰知道自己主要消费在哪里？哪些消费过度了，应该控制下的。但这一步也是艰难的一步啊！ 市面上的记账软件说到记账，第一步就是找个好用的记账软件了。市面上的记账软件很多，基本都满足需求。但！就是坚持不下去，因为每次的消费都要手工在软件上记下去，坚持了10 天坚持不了15天。换了很多了记账软件都这样，功能是满足了，但没解决我的懒惰啊。而已有时很匆忙的一笔微信转账，一下就忘了记账了。于是乎我在继续寻找适合我的记账。我的设想就是有没有可以读取信息的记账软件，然后我以后的消费都走银行卡，消费了收到信息，软件自动记录，是不是很方便？但在市面找了一圈后发现，有些记账软件是可以读取短信消费记录的，但它并不知道消费的分类，需要自己的手选是个大工程。然后各种卡的话也容易混淆。原本想自己找时间写一个的，读读短信信息应该没什么难度。但后来我找到了一个比较理想比较适合我的记账软件，也就省得我自己开发了。 微信记账本我的最终选择就是微信记账本。是一个小程序很方便也不用安装。他可以读取你的微信各种消费和各种收入信息，我本来的比较多的也就是微信支付，除了keep会员是华为支付，京东购物用的是京东支付外，都是走的微信支付，自动记录。现在我只要要用其他不走微信支付的支付方式改成微信支付就好了。比如取消keep在华为支付的自动续费，改微信支付自动续费。京东购物也不用京东支付了，直接走微信支付，这样就搞定了，是不是很方便？而且微信记账本有一个好处就是商家走微信支付时，每一笔的消费都已分好了消费类目，所以可以自动给每笔消费分类，而且你的微信转账，收发红包都会一一帮你记录，实在太适合了。微信的确定就是淘宝购物吧，好像不支持微信支付的，需要手动去添加记录。还有就是银行卡的收入比如工资，也要自己手动去添加记录，还好的是微信记账功能有个提醒功能，比如工资，你可以设置个提醒，每个月发工资时提醒添加工资收入记录。而且在微信的生态里，我们平时用得最多的就是微信了，可不大可能会错过没看到提醒。如果你觉得也很懒，不妨按照我的方式试下微信记账本吧。如果你觉得对你有帮助，可以请我喝杯奶茶哦😬

背景最近在玩AE做动画，导到ME,然后渲染生成视频, 视频有配音是AI合成的。在AE预览的时候是没问题的，但是在ME渲染成视频后，视频的第一句音频渲染总是有问题的，很快，也变了调。而且只有第一句有问题，后面的语音音频都正常。 解决方案这个问题找了很久一开始以为是AI生成的语音音频有问题，几重新生成了次，换个格式都不行，把后面正常语音替换第一句语音，发现还是一样，确认和音频无关。然后我才猜想是不是渲染的格式或者用来渲染的某些选项问题呢？后来试了很多都不行。最后想为什么只有第一句怕的，然后我把第一句语音删了，发现不怕了，可能就是因为第一句太靠前了，视频刚开始就有一段语音音频，然后我尝试把吧原来的第一段语音音频，拖后面一点，最后没玩解决的！记录下，也方便遇到同样问题的人

Sequelize 简介sequelize 是nodejs里面很成熟的数据库ORM，配合nodejs使用，开发事半功倍。相较于其他语言ORM，sequelize 有着一整套完整的解决方案，包括各种复杂的查询，联表，数据库表的设计与生成等。 本文主要记录各种负责的数据查询使用sequelize如何实现，还有记录一些坑或bug。 sequelize include order写过原生sql查询的人都知道，排序都是在最外层排序的，所以一下代码无效: ctx.model.User.findAll({ include: [ { model: ctx.mode.Book, as: 'books', order: [['createdAt', 'ASC']] } ], order: [['createdAt', 'DESC']] })以上查询最外层的order是有效的， 但是里面include层的books数组排序是无效的，会导致每次查询的数据顺序不一样，要指定include里面数据的排序，应该这样写 ctx.model.User.findAll({ include: [ { model: ctx.mode.Book, as: 'books' } ], order: [['createdAt', 'DESC'], order: [['books', 'createdAt', 'ASC']]] })类似于原生查询的A.createdAt

关于Vue-router=>addRoutes 方法的一些坑 router.addRoutes(routes: Array<RouteConfig>) routes 是要符合路由规范的数组 router.addRoutes 只是注册了路由的规则，但是并不会自动更新路由列表项，需要先手动更新路由列表，再去注册规则 // 手动添加路由列表项 router.options.routes.push(...routers) // 注册路由规则 router.addRoutes(routers) 注册完最好重定向 如果添加路由之前，要访问的地址是需要 addRoutes 添加的。 那么在调用addRouters之前路由并不存在，所以注册完需重定向一下要访问的地址 在路由导航守卫可以这样些 router.beforeEach((to, from, next) => { // 其他逻辑 router.options.routes.push(...asyncRouterMap) router.addRoutes(asyncRouterMap) next(to.path) }) 动态引入组件component 网上很多人的文章的copy的，也没验证过，所有导致搜索的大部分方法都是不行 component: () => import(componentPath) 不行 component: () => import('@/' + componentPath) 不行 还有很多的网上办法都不行的 最后找到了解决方法： component: require.ensure([], (require) => { resolve(require('@/' + componentPath)) }), 注意： @/ 要分开写死，不可以连同地址一块传入，可能是为了给webpack标识的

前言因为自己有养猫，对流浪动物啊也时常关注，想多多少少出一份力啊。 我逛了下一些宠物机构，发现了很多宠物机构，没有自己的宠物管理系统，用户难以线上浏览可以领养的宠物，且每个机构的可宠物信息并不共享，就一定程度上加大了用户领养的难度，想领养的人只能线下一间间跑，看有没有合缘的宠物领养。 而且一些个人的宠物生了，需找人领养，只能发发朋友圈，信息扩散程序可想而知，从而加大了领养的难度。 所以我就想做一产品，可以给想领养的人，在线上可以看到身边可以领养的宠物，看上了就具体线下了解。 也可以给一些没有技术支持的机构/个人提供一个宠物的发布等管理系统让领养可以跨上那么一小步。 项目状态项目现已完成了基本功能上线，功能会不断的迭代更新。 大家微信搜索51领养 就可以查看，或者扫描一下小程序码即可 宣传项目刚上线啊，也不知道怎么宣传好，大家可以给给意见。 我自己做了张海报，不嫌弃的可以帮忙宣传下。

前言最近在打一个多页面的手脚架，因为经常会接到一两个页面的临时活动的开发需求。 vue开发栈喜欢了，想用vue来开发，有感觉有点累赘，大材小用的感觉。 直接新建个html，手撸起来又各种问题，导致开发效率低下，例如: 平时用惯了es6语法，要写回es5,要经常查文档 不能使用预处理样式(less,sass)，这个效率大打折扣啊 手动页面优化(压缩，去除注释,检测语法) 本着现代开流，还是自己根据自己的需求撸个基于webpack的多页面开发手脚架，虽然没用vue，但是开发的流程基本跟vue开发流程一直，能自动化的部分都自动化，能提高开发效率的都用上，以后再也这类需求，就直接拉下手脚架，开发就行，不用再另外一个个配置了。 本以为大功告成，却忽略了一个问题，就是有时几个页面的头部或者底部是共用的，这时候需要分离出来，不然三个页面个三个一样的头部，要修改头部时也要修改三个页面，这很不好维护。 于是乎就寻找各种方案了 html 引入模板 iframe 首先淘汰了这种方法，因为iframe算是历史遗留产物，而且会引起许多的bug，能不用还是不用吧。对iframe真心没好感。 模板引擎 这是开始确认的方向，因为之前玩node用过ejs，使用起来简单方便，于是乎在网上找了各种方案，但还是没找到合适的。 一种是基于一个布局模板去生成html，但这不够灵活啊，不是所有的页面都一定要基于那个模板，比如有几个页面公用一个头部，另一个页面公用另一个头部这样，我能根据自己需求来引入才是完美的，而且ejs并没有继承的功能，不能再一个模板上追加内容，也是个大问题。 第二种就是项目直接全部用ejs，webpack解析打包成html。虽然解决了上面的问题.但对于前端开发来说不是很友好，都变成了.ejs后缀了，最终还是舍弃了。 html-loader 的 interpolate html-loader 大部分人都有用，甚至在解决这个问题前我自己也用了，但大部分人都想我一样，用来处理html文件中的静态资源文件，但其实有一个引入模板的功能。 首先要在webpack rules里加上加一条处理html的规则 { test: /\.html$/, use: { loader: 'html-loader', options: { // 处理html 引用的图片 attrs: ['img:src'], // 开启 html模板功能 interpolate: true } } } 然后在html文件就可以直接引入其他html模板了 <!DOCTYPE html> <html> <head> <title>index</title> ${require("../layouts/head.html")} </head> ${require("../layouts/header.html")} <body> ${require("../layouts/footer.html")} </body> </html> 简单又灵活，Get it！ ​ 最后也分享下自己配置好手脚架：webpack-multiple-pages-template

前言由于我是一名前端开发者，偶尔会接一些私单，最主要的无非就是帮人做网站了。 CMS根据以前的经验无非就是前端写完界面，然后找一个cms去套，但由于国内的cms框架（duxcms我之前一直用,dedecms.phpcms,wordpress）已经很难满足了现在的客户需求了。 比如做个网站，一开始以为做个网站就行，谁知道还要做小程序，App等等，但之前的cms都不带api，即使有写带比如wordpress，api接口也是问题多多的。 然后可以看国内开发的cms，即使的新开发新产品，也是比较保守的，还是跟以前的cms差不多，无非就多提供了api 供用户调用，然后后台操作界面交互也不咋地，所以很难找到一款非常合适的cms框架。 ​ 而我感觉国外的就比较思想超前敢冒险尝试，既然api方式通用，那我就专门做提供api和后台内容操作的cms，数据和界面教还给前端，自己爱拿什么数据那什么数据，唉什么布局怎么布局，前后分离。然后cms就专心做好内容管理和api接口的设计就可以了。 虽然这个想法早期还有点冒险，比较像这种前后端分离的spa还有有很多问题的 做网站的人很看重的seo问题 首屏加载速度问题 问题虽然有，但方向应该是对的，就看怎么解决这些问题而已。 为什么写网站也要用spa​ 而且平时在公司或者自己写前端，写法习惯都已经从jq过渡到了前后端分离框架vue、react、angular等写法的习惯了。然后接了一个私单，又要突然转回去以前那种jq操作dom的 时代。 这个过程实在难受，而且效率也低。 有没有办法开发个网站也能使用现代化的开发流程和各种工具，然后解决seo，和首屏加载慢等spa问题的。 于是乎后面出现了各种ssr服务端渲染框架，去帮spa应用解决这些问题。 SSR 服务端渲染框架 使用SSR（也称为“通用”或“同构”）模式，将使用Node.js服务器将基于Vue组件的HTML传递给客户端，而不是纯JavaScript。 — nuxt.js 目前主流有两个: vue 架构的 nuxt react 机构的 next 两个都是开箱即用的，大大降低了开发部署的难度。 主要用那个技术栈就用那个框架吧，react好像还有个 gatsby好像挺好用，但我不主要react技术栈 ，所以就没深入了解了，看了文档和别人介绍感觉挺不错的，react技术栈的同学可以去了解下。 前端的开发框架我们选好了，然后我们就要选个后端的cms 去管理数据，提供api接口调用数据了。 我们先来想一下我们期待的cms是怎样的: 内容可定制化程度高，因为网站有各种功能，比如轮播的海报，收集用户表单，新闻站的文章，画册张的相册等。 后台交互良好，至少交付给客户时，客户很快有会用。 良好的api接口设计 对gatsby友好 提供全平台sdk headless cms 翻译一下就是只提供纯api的cms，不包含任何客户端代码，也就是老子只负责api你手机，还是网页想咋用咋用。 — 摘抄自北方蜘蛛 Contentful你搜headless cms，然后到处都能看得到Contentful 来说说它的强大之处： API-First CMS to Power All Digital Products | Contentful 简单翻译就是第一个只提供api的cms吧，先做有经验优势嘛 免费，不用自己部署，但有一定限制 Serverless 架构部署，可能就是用了serverless 才有可能有免费的提供用吧 提供restful 接口 + graaphql 接口 支持多站点，多项目，但需另外收费。 可以说contentful是个先进技术集合的cms，各种现代化技术集合一体。 然后操作界面也比较简单简洁，感觉是挺不错的，操作还是流畅的，还提供多角色共同管理。 但作为接私单来开发网站还是有些问题的: 不开源，所以不可以自己部署。你做完交接，要客户登陆别人的网站去管理，这样不大好吧。 后台管理不支持中文，怕客户看不懂，不好操作。 不收费的有限制，感觉以后也会慢慢变成收费的，收费项又确实比较贵 暂时没看到内容的导出与导入 strapi我试了挺久的一个，功能也简单，界面也简洁。 优势: 开源免费，可以自己部署 简单又便捷，添加内容模型，添加内容，然后设置用户对这个内容接口的权限就好了 规范的restful接口，且接口信息简洁，没有返回其他很多没有必要的东西 ///banners [ { "id": 1, "title": "轮播海报", "link": "sadasdasdasd", "created_at": "2019-11-14T07:19:50.350Z", "updated_at": "2019-11-14T07:19:50.350Z", "image": { "id": 1, "name": "teacher-avatar.gif", "hash": "466289966ffd4599afd646ede29bac40", "sha256": "kgeU5VQ-bYTbtNlEwoTi_4LPykpIPxrtZLtlL-ehyAY", "ext": ".gif", "mime": "image/gif", "size": "1.48", "url": "/uploads/466289966ffd4599afd646ede29bac40.gif", "provider": "local", "provider_metadata": null, "created_at": "2019-11-14T07:19:50.471Z", "updated_at": "2019-11-14T07:19:50.471Z" } } ] 后台字段布局可自由拖动布局 有国际化，虽然中文的有些翻译有些蹩脚，有些也没翻译，但总比全英文好啊 也提供Graphql接口 感觉strapi虽简洁，简单，但功能齐全 个人感觉的缺点： 不支持多站点多项目 比如我想自己搭一个数据管理中心，给个各个网站使用，每个网站都有新闻内容模块 这时候我不能建一个新闻内容模块一起用，这样数据就混乱了。只能布置多个strapi或者新建多个新闻内容模块，以区分不同网站的新闻内容模块。 其实有考虑过根据新闻模块关联用户、根据用户去区分新闻模块对应的数据，这是一个可行的方法。但只只对没有用户系统的站点或项目，不然就又轮到用户信息混乱了。 但是用户又可以根据用户组去区分，感觉还是可以实现的-> 根据添加不同用户组然后添加用户，去区分不同的网站，从而去同一个内容模型拿对应的内容数据 但说回来，要不同项目用统一个模型，两个项目的统一模型要高度统一，不然还是有很多问题的。 期待strapi后面可以有站点或者项目的概念，在站点或项目下，再去新建不同的内容模型，这就完美了。 ghost我用过算最好的博客系统吧，性能飞跃，后台管理、写作交互,体验都完美，也有很多很漂亮的，后来因为服务器到期了，续费太贵了，于是才把博客迁移到了hexo+github pages 免服务器啊，还可以https，当然速度和原来的没法比啊。而且你github 搜 nodejs 的 headless cms 第一名就是ghost,第二是``strapi` 个人感觉的优点: 简单简洁，为博客而生，主要就添加文章或页面 完美的写作体验，完美兼容markdown和html 写作,也可以一篇文章即html又有markdown 主题精美，速度飞快，后台操作也很友好 即提供服务端渲染，也提供api 代码开源，却已盈利 完善的开发手脚架，不仅可以初始项目，更包括集成 Let's Encrypt 自动帮你生成ssl证书，配置nginx ssl配置,等等…… 个人感觉的缺点: 主要专注于博客，对于一些网站的其他功能还是显得有些不足。可扩展性不强。 虽提供api，但不是restful 规范的 主题虽精美，但相对于wordpress 还是相对较少的

前端错误监控系统服务端其实线上已经有很多监控系统了，例如fundebug。试用了一下还是挺不错的。可惜都是收费的，免费的只能创建一个项目，收费也不便宜。对于一些小公司来说很难花钱去搞，而且对小公司来说功能也不需要太复杂。一些js的报错和接口报错就可以大大加快bug的修复，和预知bug。（当上级和测试都还没发现时）所以我还是写这么个系统，是从自身需求出发吧。功能可以慢慢完善。 现在初期只实现了简单的js和接口资源报错。后期会加入UA和用户等信息以完善错误信息追踪错误。对服务端还是新手所以代码质量….graphql也是试手。但好在错误监控系统一般内部人使用，独立不影响线上项目和用户。所以大胆地使用吧。 项目集 服务端 frontend-sniper-server 管理后台 frontend-sniper-admin 错误探针 better-js todo 支持vue 邮件通知（新错误报错，旧错误5n次发邮件报错） 添加UA信息 添加用户信息 记录用户行为 手动上传报错

mysql group by 和 order by 一起用失效我自己写了一个前端错误监控系统。 前端有各种报错，后台就会自动发邮件通知、 这里就会遇到同一个错误可能很多人遇到，或者同一个人遇到很多次。 这样同一个错误就会有很多次报错。 当管理员进入后台时，看到很多同一个错误的报错，这很明显不人性化。 于是我就设计成，同一个错误的合并，只显示最新那个。 一开始sql写法为 SELECT * from `errors` GROUP BY `title`,`msg`,`category`,`level`,`appId` ORDER BY `createdAt` DESC 发现同一个错误是合并了，但是 ORDER BY 并没有生效，合并后的错误不是最新的一条错误而是最早的一条。于是查了资料发现，GROUP BY 没有排序功能，默认取合并时的第一条。于是就想到了，先排序完再合并就好了，于是有下面代码： SELECT * FROM (SELECT `errors`.*,`apps`.name from `errors` LEFT JOIN `apps` ON `errors`.`appId`=`apps`.`id` WHERE `apps`.userId=1 ORDER BY `createdAt` DESC ) as result GROUP BY `title` ORDER BY `createdAt` DESC 但发现还是没用啊，我百度了下，很多人也是这样写的，但为什么就不生效呢？经过一番查找，终于找到原因了，mysql版本的问题，以上的代码在5.6或以下的代码应该都可以的，但在5.7则要加limit条件，不然子查询是不执行的，完整代码如下 SELECT * FROM (SELECT `errors`.*,`apps`.name from `errors` LEFT JOIN `apps` ON `errors`.`appId`=`apps`.`id` WHERE `apps`.userId=1 ORDER BY `createdAt` DESC LIMIT 100) as result GROUP BY `title` ORDER BY `createdAt` DESC 是不是很坑。。。 记下先

前言现在的开发基本都是前后端分离的项目，既解放了前后台各自的生产力（后台专注写业务给出数据就行，再也不用管前端UI的事。前台专注于写UI拿数据就行，再也不用跑后台服务，不用打开eclipse了）又可以一套代码兼容多个项目：APP，网页，微信，微信小程序等。 但在开发的过程中发现了，现在后台普遍用了自定义code去判断接口的成功失败信息。而http code则变成鸡脖，除非是服务器蹦了之外，其他一律返回200成功。为什么会有这个现状呢？具体不是很了解啊，据说是以前IE上有些http code报错会导致IE一些问题。不知道是不是，知道的可以给我科普下。 而在开发中使用自定义code也并没有什么问题，例如我们的项目一般接口返回的response信息完整结构： { data:{ data:{ userList:[ {id:1} ] }, rcode: 300, message: "操作成功" }, engine:'.....', headers:{//....}, request:{//....}, status:200, statusText:"request:ok" } 而我们开发中一般用一个拦截器去拦截接口中的错误和返回接口要用的东西，不用的heades我们就不返回了。例如: response.use( (response) => { if(response.data.rcode===405){ //统一处理某个自定义错误code }else{ return response.data;//返回我们要用的数据 promise.resolve(); } }, (err) => { //httpcode 错误 默认返回200，所以只要处理500以上的服务器问题即可 //发生网络错误后会走到这里 if(err.status>=500){ //统一处理某个httpcode 500以上错误 } } ); 使用了拦截器后我们正常得到的数据格式如下: { data:{ userList:[ {id:1} ] }, rcode: 300, message: "操作成功" }, 但我们请求完数据后必须判断rcode是否成功才好操作,否则会报错，例如 let res=await this.api.getUserList(); if(res.data.rcode==300){//要先判断是否成功,否则失败下面语句会报错找不到'userList'，接口失败是没有返回userList的 this.userList=res.data.userList; } 以上就基本大部分公司的写法，也没什么问题。但写多了（例如：100个接口）就会发现,100个接口，前端就要写100个if(res.data.rcode==300)。能不能有办法优化下。 后来用接触了nodejs 自己写后台接口发现是可以优化的，而且对于接口比较多的项目，效率可以大大的提高，对于前后台都是。那就是用httpcode替换自定义的code。 先来说说httpcode相对于自定义code的好处 规范，httpcode的规范有国际的规范，百度搜一下就有。而使用自定义code规范都是自己定的，而且每个项目的定义code的字段，每个值的规范也不一样容易混乱。如果每个项目都用httpcode 都用国际的规范这样是不是会好很多？ 对于后端开发来说使用httpcode可以大大增加效率，例如： 使用自动code时输出数据 //成功时 this.body={ data:{ userList:[{id:1}] }, rcode:300, msg:'成功' } //失败时 this.body={ rcode:400, msg:'失败' } 使用httpcode是，因为默认输出都是200，只有错误的的是否才需要去定义错误码： //成功时 this.body={ userList:[{id:1}] } //失败时 this.status=400; this.body={ msg:'失败' }你可能以为也就简单了那么点事，可是当有100个接口时呢？效率就是从这里来的啊 对于前端开发来说使用httpcode也可以大大增加效率，例如： 拦截器就不用去判断自定义code 而直接判断httpcode： response.use( (response) => { if(response.data.rcode===405){ //统一处理某个自定义错误code }else{ return response.data;//返回我们要用的数据 promise.resolve(); } }, (err) => { //httpcode 错误 默认返回200，所以只要处理500以上的服务器问题即可 //发生网络错误后会走到这里 if(err.status===400){ //统一处理某个httpcode 错误 }else if(err.status>=500){ //统一处理某个httpcode 500以上错误 } } ); 然后再来对比下使用httpcode和使用自定义code的数据个操作：//自定义code时返回数据 { data:{ userList:[ {id:1} ] }, rcode: 300, message: "操作成功" } //httpcode时返回数据 { userList:[ {id:1} ] }, //自定义code时操作 let res=await this.api.getUserList(); if(res.data.rcode==300){//要先判断是否成功,否则失败下面语句会报错找不到'userList'，接口失败是没有返回userList的 this.userList=res.data.userList; } //httpcode时操作 let res=await this.api.getUserList(); if(res){//要先判断是否成功,否则失败下面语句会报错找不到'userList'，接口失败是没有返回userList的 this.userList=res.userList; } 虽然感觉就优化了那么点，但真正写起来，那么多个接口，你就会感觉显明方便多，效率也快乐。