最近接手了个集团一体化前端项目，因为承载了多个产品线的业务模块，代码量巨大，本地启服务时总是会内存溢出，启动老是失败。今天给大家分享下解决内存溢出问题的心路历程。

前言 上周在群里突然被 @ 要我查看生产上出现的问题，由于这个项目比较老 (React15)，既没有埋点也没有接入错误监控，于是会得到如下的这样一个提示信息（以下错误是本地模拟的实际生产效果）： 当你

在前端异常解析中介绍了异常的解析，这些异常信息上报后，一般也难以直接的看出什么错误源，因为正式的线上环境中，代码往往都经过了压缩混淆，异常的一些信息都是指向压缩文件。这时候可以根据 Source Map 文件追溯源文件的位置。 最初的源映射格式是由 Joseph Schorr …

作为一个兢兢业业的前端er，虽然每天都被各种CRUD的需求包围着，但总归还是有一颗爱玩的心。这篇文章也是之前想要做的一个小玩具，最近终于挤出时间把这个玩具给实现了，感觉有点意思，整理出来给掘友们玩一下

使用 sourcemap 方式进行线上和开发环境调试，不同环境下使用不同的方式。以及怎样在线上环境下开启 vue项目的 dev-tool。

前端异常种类有哪些？怎捕获异常？sourcemap到底有啥用？如何搭建一个错误监控的平台？关于那些前端异常的秘密，本文结合源码带你一一揭开！！！（文章内容较长，需要点耐心啦~，先赞后看，年薪百万！！）

前言 项目上线之后，用户如果出现错误（代码报错、资源加载失败以及其他情况），基本上没有办法复现，如果用户出了问题但是不反馈或直接不用了，对开发者或公司来说都是损失。 由于我这个项目比较小，只是一个迷你

如何调适线上代码 这篇文章来分享下如何调试线上的代码 什么时候需要调试线上的代码呢，当线上代码出现 bug 的时候，需要定位问题，就需要一步一步调试代码来确认问题，但是线上代码都是构建之后的代码，很难

我们发布到生产环境中的代码，往往都经过压缩和混淆，文件名、函数名、变量名已经不具有可读性了，捕获的异常堆栈信息的价值有限，简单的通过这些异常信息，我们依然很难定位到源文件中错误出处。本文我们就试图解决这个问题：基于 AST(抽象语法树) 对源代码进行 try catch 包裹，并在 catch 语句中收集更多源文件的信息 (包括文件名、函数名、函数起始行号等)，最后借助于 babel 和 webpack 的插件体系，提供一个工程化的解决方案。