前言
Fundebug帮助我们解决什么问题？
- js运行、资源加载、http请求错误实时邮件报警
- 错误源码调用栈定位
- 用户行为记录
- 细化适用前端各种框架
- 业务主流程监控上报自定义扩展
已经有了countly监控，为什么不对countly做二次开发？
- 当然能在countly实现我们想要的上述功能最好，不过时间、人力成本略大；架构组调研前端异常监控几款产品，最终选择了Fundebug。除了现价段能满足我们的需求外，接入成本较少，易于扩展，轻巧而专项能力强，可视化界面清爽的优点。下面由我来介绍针对我们现有的框架及项目，怎么科学地接入使用。
起步走
- 前往https://fundebug.com/，用公司邮箱注册，告知不惑加入团队相应项目。如果是项目经理，向不惑换回自己项目的apikey（类似countly的appKey）。
- 回到自己的项目，安装
npm install fundebug-javascript fundebug-cli --save
在package.json中做些手脚，请参考我的方式，加入
"config": {
"funDebugKey": <apikey>
},
"scripts": {
...
"clean:map": "rimraf build/*.map", // 生产环境不需要*.map文件
"upload:map": "cross-env fundebug-cli upload --apikey $npm_package_config_funDebugKey --directory build/", // 源码定位需要上传至Fundebug
"compile": "cross-env DEBUG=app:* node bin/compile && npm run upload:map && npm run clean:map", // 一键压缩
...
},
-
找到webpack入口文件，image.png
在第一行导入
import fundebug from 'fundebug-javascript';
然后初始化
fundebug.apikey = <apikey>;
变量只改动一处的原则，这里最好取package.json里的内部变量funDebugKey，不知道怎么取？莫慌，用webpack的DefinePlugin将它变为全局变量，参考如图：
image.png
image.png
还有几个参数值得去配置，appversion也从package.json里读取，user.name帮助我们快速定位用户，releasestage区分不同的环境。用户登录后，user.name需要再次赋值。
总结
Fundebug的接入到此正式完成，静静想想，还是要做成npm包比较好，像countly一样，原因一个是统一维护，一个是可限定入参标准，一个是做到最优先执行，一个是方便后续扩展，好处多多，这里暂不考虑吧。
值得一提的是，要支持错误源码定位，都应开启webpack的sourcemap功能，务必检查。但在生产环境中，我们又不想将源码暴露到浏览器，不用担心，前面一键压缩命令在上传完后自动删除*.map文件，目前有个小小的问题，就是浏览器控制台会报警告找不到相应的*.map文件。瑕不掩瑜，积极拥抱。
