nodemon 在js文件变化后悔重新运行程序，在 package.json 的 scripts 中添加：
nodemon还有许多可选配置，具体参阅 nodemon文档
以koa为例
如若想要将错误抛出到浏览器页面和美化错误页面， express 可用 express-error-handler ， koa 可用 onerror
由于是后台模板渲染，所以没法用 webpack-dev-server 进行自动刷新。能做的就是利用 webpack 的 watch 在前端js改变后自动打包，当然还是免不了手动刷新
注意一定要开启 source-map ，不然无法定位报错位置。为通知 webpack 是生产还是开发环境，可以使用 cross-env ，然后在 package.json 的 scripts 中添加：
开发时应运行两个命令：
生产环境一般使用 pm2 ， pm2 已经帮我们完成了进程守护和负载均衡，内部实现原理在此不再赘述，具体参考 pm2文档 。
生成的配置文件已包含了生产环境的基本本质。跟多配置请参考 pm2文档 ，在 package.json 文件的 scripts 中添加
生产环境下运行
这时我们可以通过 process 全局变量获取到环境状态，在 app.js 中添加
类似 nginx 的 access.log 和 error.log ，利用 fs 模块的 appendFile 方法来输出日志。首先在项目根目录下新建文件夹 logs
建立一个模板命名为 notFound.pug ，在路由之后渲染
在webpack中添加插件
发布应用时需运行
2. 做点击跳转, 用户点击后先跳到自己服务器上, 然后由自己的服务器做重定向, 并记录这一次请求3. 前端 JavaScript 监控用户鼠标行为, 并及时上报到服务器
这三种方法也分别有各自的优缺点, 当时分析的是
2. 绝对完整的记录. 不过需要新增服务器响应跳转请求, 并且如果跳转服务挂了会让用户压根到不了 url 指向的地方. 目前所有的广告服务都是这样 (而且点击串加密), Google 的网页搜索很早就是这样, 百度跟 360 干上后也换成了这种. 根据度厂员工在新浪微博上跟别人的讨论, 即使是百度网页搜索那么大的量, 算上灾备最多 50 台跳转服务器可以搞定 (根据公开资料, 百度每天网页搜索量在十亿这个量级, 按搜索引擎页面点击率 30% 算, 每天至少三亿次点击跳转请求)
今天跟前端同学讨论, 终于搞懂了为什么是这样. 后端的思维是每发生一次事件就打一条日志, 所以极难发生日志丢失的问题. 而前端不能每发生一次事件就向服务器发请求打一次日志, 这样会带来很大的网络开销并拖慢用户的浏览器, 所以前端都是把要纪录的行为在用户端先缓存, 等积累够若干条或过了若干秒后才向服务器汇总上报, 如果在这个上报条件触发前浏览器崩溃掉, 那日志就没了, 或者用户关掉浏览器也会丢掉这部分数据 (据说有一些方式可以响应关闭事件并上报日志, 但具体方式不了解, 另外前端同学反馈 IE6 下丢数据现象更严重). 所以丢数据这事其实是用户流畅度体验和数据完备性的一个平衡, 如果让用户卡一点那丢失比例就低一点. 另外接 js 汇报日志的服务器压力也是一个要考虑的点, 因为如果真用 js 汇报, 那一定就不止点击这点数据了, 鼠标滚轮, 悬停等事件显然是能有都有, 服务器不一定扛的过来.
