实际上自己接触 Rust 的时间还是很有限的，这里也不会对 Rust 进行长篇大论地介绍，简单来说，Rust 是一个性能和 c++ 相近的系统级编程语言，同时，由于其所有权与变量生命周期等机制的设计，使其相对于 c++ 来说拥有内存安全的优势，几乎不会出现诸如悬垂指针、数组越界、段错误等问题，在微软、百度、字节跳动等公司均有所使用。
关于 Rust 的特性以及未来，知乎这个问题中的一些高赞回答以及相关的评论，非常值得一看。
本文会以二叉树这样一个具体的例子出发，来对 Rust 的一部分知识内容进行学习。
viola 是一个支持 Vue 的动态化框架，其 Vue 版本在 Vue 官方版本 2.5.7 上进行了少量改写，本文针对其进行具体分析。
最初，有使用者报告一个错误：在 iOS 系统，退出页面的时候，框架报错：
TypeError: undefined is not an object(evaluating 'e.isDestroyed"
接到这个错误之后，我首先进入 Vue 的 debug 版本，尝试获取更详细的信息：
TypeError: undefined is not an object(evaluating 'componentInstance.isDestroyed"
我们顺利地拿到了报错的变量名称，去 Vue 源代码中搜索，我们可以发现报错之处：
destroy: function destroy (vnode) {
var componentInstance = vnode.componentInstance;
if (!componentInstance._isDestroyed) { // 这里报错
if (!vnode.data.keepAlive) {
componentInstance.$destroy();
} else {
deactivateChildComponent(componentInstance, true /* direct */);
}
}
}
这里是 componentInstance 为 undefined，这个实际上是 vnode 的实例，其为 undefined，说明该 vue 组件在之前的阶段就已经出错不正常了，这里并不是错误的根源所在，我们需要再次进行寻找报错原因。
于是我们查看业务代码的所有日志，又发现了这样一条报错：
[Vue warn]: Error in nextTick: "TypeError: undefined is not an object (evaluating 'vm.$options')"
初始化阶段出现这样一个错误，我们怀疑 vm 就是上文的 componentInstance，于是，我们打印报错堆栈：
调用栈:
function updateChildComponent(
vm,
propsData,
listeners,
parentVnode,
renderChildren
) {
//...
var hasChildren = !!(
renderChildren ||
vm.$options._renderChildren || // 这里报错
parentVnode.data.scopedSlots ||
vm.$scopedSlots !== emptyObject
);
}
function prepatch(oldVnode, vnode) {
var options = vnode.componentOptions;
var child = vnode.componentInstance = oldVnode.componentInstance;
updateChildComponent(
child,
options.propsData,
options.listeners,
vnode,
options.children
);
}
function patchVnode(oldVnode, vnode, insertedVnodeQueue, removeOnly) {}
function patch(oldVnode, vnode, hydrating, removeOnly) {}
function (vnode, hydrating) {}
function () {
vm._update(vm._render(), hydrating);
}
function get() {}
function getAndInvoke(cb) {}
function run() {}
function flushSchedulerQueue() {}
function flushCallbacks() {}
调用栈实际上有点冗长，不过我们还是能发现两个有用的信息：
undefined 的 vm，就是 componentInstance，也就是和 destroy 阶段的报错属于同一个原因。这引发了我们的思考：更新阶段找不到 componentInstance 报错。
这里实际上有点阻塞了，因为一般来说，Vue 的源代码经过测试，应该不会出现这种问题的，那是不是我们的问题呢，我们回归到业务代码：
created() {
this.getFeedsListFromCache();
},
methods: {
getFeedsListFromCache() {
viola.requireAPI("cache").getItem(this.cacheKey_feeds, data => {
this.processData(data.list);
});
},
processData(list = [], opt = {}) {
if (this.list.length < cacehFeedsLength) {
}
this.list = [];
},
}
我们对业务代码进行了抽象简化，上面是我们的最小问题 Demo，实际上我们就做了这样一件事情：
首先，我们可以梳理下对一般 vue 组件的初始化更新，vue 是如何做的：
Promise.then 的 microtask 方式来调度，当前阶段的 mount 流程会继续，mount 结束后，会执行 flushCallbacks 队列中的更新操作。从代码层面上来讲，这几个流程应该是这样的：
├── callHook(vm, 'created'); // 执行created 钩子
├── proxySetter(val); // 改变数据，调用 proxy
├── Watcher.prototype.update; // 调用 Watcher，将 update 操作入栈
├── vm.$mount(vm.$options.el); // 执行 mount 流程
├── callHook(vm, 'beforeMount');
├── callHook(vm, 'mounted'); // 依次调用 beforeMount 和 mounted
└── flushCallbacks // 执行 更新
然后我们分析我们这里的流程，首先值得强调的是这个函数 viola.requireAPI("cache").getItem，这个函数是端注入的函数，但我们不能将其当作异步函数来对待，实际上，这是一个同步函数，（至于这个同步函数和 js 中的普通函数，是否有区别，还有待商榷，不过应该是有区别的，因为如果我们不用此函数的话，就不会出现该问题。）
接下来，我们打出详细的调用栈，根据顺序来分析实际的执行流程：
├── callHook(vm, 'created'); // 执行created 钩子
├── proxySetter(val); // 改变数据，调用 proxy
├── Watcher.prototype.update; // 调用 Watcher，将 update 操作入栈
├── flushCallbacks // 执行 更新
├── vm.$mount(vm.$options.el); // 执行 mount 流程
├── callHook(vm, 'beforeMount');
└── callHook(vm, 'mounted'); // 依次调用 beforeMount 和 mounted
我们发现，我们的执行流程出现了很大问题：在 mount 阶段未完成的时候就执行了 flushCallbacks，先执行更新操作，这里的顺序错乱导致了后续问题。
我们可看下调用 flushCallbacks 的代码：
if (typeof Promise !== 'undefined' && isNative(Promise)) {
var p = Promise.resolve();
microTimerFunc = function () {
p.then(flushCallbacks);
// in problematic UIWebViews, Promise.then doesn't completely break, but
// it can get stuck in a weird state where callbacks are pushed into the
// microtask queue but the queue isn't being flushed, until the browser
// needs to do some other work, e.g. handle a timer. Therefore we can
// "force" the microtask queue to be flushed by adding an empty timer.
if (isIOS) { setTimeout(noop); }
};
}
这里 microTimerFunc 的 p.then，被同步执行了，也就是说，这里的微任务优先于当前事件循环的函数执行了（此时由于 mount 流程是同步的，mount 流程的相关函数理应在该事件循环中，优先于微任务执行）。
我们找到了根源，接下来就是分析解决方案和根本原因。
由于我们的问题在于 update 流程执行太快了，所以采用一种方式放慢一点即可：
var useMacroTask = false; => true。setTimeout(0)。不过对于根本原因，实际上本次仍然没有完全分析透彻，还留有如下疑问：
viola.requireAPI("cache").getItem 这个函数到底做了什么？其对事件循环有什么影响？microTimerFunc 的时候，为什么 p.then 优先于 vm.$mount 执行了？对于这些疑问，Vue 源代码中也做了一些评论：
// Here we have async deferring wrappers using both microtasks and (macro) tasks.
// In < 2.4 we used microtasks everywhere, but there are some scenarios where
// microtasks have too high a priority and fire in between supposedly
// sequential events (e.g. #4521, #6690) or even between bubbling of the same
// event (#6566). However, using (macro) tasks everywhere also has subtle problems
// when state is changed right before repaint (e.g. #6813, out-in transitions).
// Here we use microtask by default, but expose a way to force (macro) task when
// needed (e.g. in event handlers attached by v-on).
不过，这里始终都没有找到最本质的原因，也许这和 iOS JSCore 的微任务/宏任务的处理机制有关，具体原因，待下次探究。
本文基于笔者在腾讯的项目经验，从真实场景出发分析一个中型 Web 应用从立项到上线稳定运行的平稳解决方案，力求既不太空泛以至于看完了仍然找不到落地的点，也尽量不会特别纠结于个别细节导致没有相关使用经历的同学无法感同身受，而是从宏观到方法论，分析整个流程中我们需要用到的工具、方法与规范，给大家提供一个参考。
本文适合具有一定经验的初中级前端开发者，如果有相关问题，也欢迎与我交流。
目录
目前在一般的项目中，我们都会使用 webpack 作为搭建开发环境的基础，而 react 和 vue 也各自提供了 cli 工具用于开发一个中小型项目，react 提供了 eject 功能让我们可以更加自由的配置 webpack，而 vue 脚手架虽然没有提供类似命令，但是借助 webpack 工具链我们几乎也可以自由定制每一个角落。
不过，这里我的建议是，如果是个人项目或小型项目，我们可以基于 react 或 vue 的脚手架进行更改使用，对于一个具备一定规模的项目团队，建议还是自己维护一套单独的 webpack 构建环境，原因如下：
我们在自定义脚手架的 webpack 构建的时候，也需要梳理出一定的目录规范与约束，这样也有利于提高后期脚手架的可维护性和扩展性，一般来说，我们也要对脚手架中的公共部分和项目私有部分进行分离，对于一个具体项目而言，可以不用改动 webpack 的项目公共部分，这样也有利于减少不同项目之间的切换成本，对于我们目前的项目，一般会有如下两个目录：
- project
- project.js
- config
- feature
- plugins
- rules
- script.js
- webpack.base.js
对于一个项目，只需更改 project 下的配置。
这里我也推荐一个前同事做的steamer研发体系，在从中也可以找到很多相关参考，最简单的方式，就是直接在steamer-simple 的基础上进行扩展。
生成目录的格式，这里需要单独讲一下。
一般来说，我们生成目录的格式都是要跟发布系统进行结合的，不过也有的时候，我们做项目的时候还没有明确要接入发布系统，或者尚不知道发布系统的格式要求，但是一般情况下我们应当遵循下面的约定：
对于我们目前的项目而言，一般情况下会有三个生成目录：
- cdn
- offline # 需要客户端支持该能力
- webserver
如果一开始我们把所有内容生成到一个目录中了，这给我们后期的改动和维护，都带来很大的隐患。
组件库这一部分，适合项目开始变得复杂的情况下进行启动，而不建议一开始进行过渡设计，建设组件库能够通过组件复用降低我们的开发成本，同时，组件库也需要专人维护，保持更新。
对于 js 文件的代码格式，诸如要不要分号、两个还是四个字符缩进等，一只争议不断，本文也不对此进行讨论，但是对于一个团队的项目集合（而不是单个项目）而言，代码风格的统一，是一个非常有必要而且必须要做的事情。
关于 typescript 的相关文章实在太多了，这里也不对此进行详细的说明，其对代码的可读性、规范约束、降低报错风险等都有很好的改进，对于越复杂的项目其效果越明显。
另外， typescript 入门教程的作者也在我们团队中，这里我想说，如果现在还没有开始使用 typescript，请开始学习并使用 typescript 吧。
除了 typescript 以外，在代码格式方面还建议使用 eslint 和 prettier 来进行代码格式的约束，这里虽然 eslint 和 prettier 两者在某些情景下会有些重叠，但是两者的侧重点不同，eslint 侧重于代码质量的检查并且给出提示，在某种层面上，可以看作是 typescript 的补充，而 prettier 在格式化代码方面更具有优势，并且 prettier 在设计之初就考虑了和 eslint 的集成，所以你可以完全放心的在项目中使用两者，而不用担心出现无法解决的冲突。
另外，eslint 社区中已经形成了很多种最佳实践，而我们团队也设计出了自己的一套 eslint 规则，可以按需取用
p.s. 目前 tslint 后续计划不在维护，转向 eslint 增强，因此我们在项目中可以不再使用 tslint。
以上这几种代码风格方面的约束，适合项目之初即开始约束，这样在中后期会有巨大的时间成本的节省和效率的提升。
使用 git 进行协作这里其实包括两个点，使用 git 管理项目与自建 gitlab，后者是一个比较基础性的工作，并且实际上难度并不大，我认为每一个公司都可以使用自建的 gitlab 进行版本管理，这个实际上难度并不大，并且可以有效的保护公司的代码财产，如果你所在的公司还没有，那么这也是你的机会。
在具体的使用 git 中，对于git的分支/TAG管理、PR规范、提交文件约束等都应当有一套合理的流程，这里我对几点比较重要的进行说明：
测试是代码开发中重要的一个环节，但实际上对于前端开发来说，前端开发工程师一般较少书写测试用例，也并没有专业的测试开发工程师来辅助工作，不过，一般会有配备系统测试工程师在黑盒的情况下进行冒烟测试和功能测试以及整体链路的验收，俗称“点点点”。而这个时候，前端开发要做的就是把程序代码部署到测试服务器上，同时提供一个尽可能真实的场景供测试进行测试。
在笔者经历的项目中，虽然也使用了单元测试、端对端测试，不过这一部分体系并不十分完备，并且可能也不是大多数前端开发者感兴趣的内容，所以这里主要总结如何进行高效的测试部署与发布对接。
一般来说，我们一般会有一台到多台 Linux 测试机，供测试环境部署使用，对于前端项目而言，一般不需要特殊环境，可以进行 webpack 构建以及有 nginx 进行转发即可。
而测试环境的部署，如果是让我们手动登录去部署，显然是不合理的，如果我们纯粹使用 CI 来完成这件事，则对 CI 工具的能力和项目人员素质有一定要求，并且不具备可视化管理能力，容易出错，这里我建议可以维护一个可视化系统来进行测试环境的部署和管理，其整个环节应该是这样的：
本地代码 -> gitlab -> 测试系统部署 -> 对接发布系统
这里的测试系统，实际上是从 gitlab 拉取代码，并且本地执行 build 命令（一般是 npm run build）并把构建结果存储在 nginx 可代理的目录即可，出于系统完备性考虑，一般我们会有多台测试机，这里我建议一般拿其中的一台作为构建机，其他的测试机仅提供 nginx 代理能力即可，我们在一台构建机中进行构建，并且将构建结果通过系统命令发送到其他的测试机。
一台构建机可以服务于所有的项目，这里还可能涉及到 webpack、nodejs 版本的维护，我们需要约束各个测试项目构建处在一个相对独立的环境中，我们也可以使用过 Docker 来进行构建，保证隔离。
构建完成后，一般我们借助 Fiddler、Charles、Whistle 等任意一款代理工具，即可以进行测试。
对于前端项目而言，即使我们已经使用了 typescript、eslint 并且也有了一些测试脚本和系统测试工程师进行的功能测试，我们还是免不了会出现 js 脚本错误，特别是 js 代码的运行环境和设备的多样化，很多错误我们并没有发现，但是产品、运营同学却出现了，或者到了线上在用户设备上出现了。
所以，有两个事情我们必须要做：
对于第一个功能，进行细分，我们需要做这样几件事情：
不过这里并没有完全实现以上三点的开源库推荐，可以在 vconsole 或者 mlogger 的基础上进行适当扩展，完成相关功能。
对于第二个功能，我们需要一个完整的统计分析与管理的错误系统，这个如果自行开发的话，难度会比较大，这里强烈推荐 sentry，可以非常方便的使用 Docker 部署到服务器端，并且拥有非常强大的日志错误分析与处理能力，通过结合 JavaScript 的 sourcemap ，可以给我们的错误定位带来极大的方便。
总之，日志查看与脚本错误监控，是比较重要但是同时容易被忽视的地方，很多时候，我们的系统在线上使用了几个月了，真正有问题反馈了，我们才会考虑加上这些功能，但这个时候通常已经造成了损失。
发布系统，一般作为前端最后环节的系统，通常会和测试部署系统打通（或合二为一），一般的发布系统的必要功能如下：
至于一些其他的日志、报表等辅助性功能，则根据需要满足，这里不再赘述。
灰度发布是大型项目在发布时的常见方法，指在发布版本时，初始情况下，只允许小比例（比如1-5%比例的用户使用），若出现问题时，可以快速回滚使用老版本，适用于主链路和访问量较大的页面。
对于前端的灰度，实际上有以下几种方案：
最后一点，我们还需要一个访问量实时监控系统，我们上述有了错误查看与脚本监控系统，但是对于我们的各个页面的访问量、点击率等指标，通常是产品/运营同学比较关心的，同时访问量的波动情况也是项目健康度的一个表征（访问量突然大幅上涨或下跌，一般都有其特定原因），所以我们需要访问量实时监控系统。
而实际上访问量监控系统也有两种不同形态：
通常情况下，前者的功能是实时或者低延时的，而后者由于需要一部分统计分析，通常可以接受非实时情况（一般每天出前一天的报表）。
这部分内容，需要较强的后端接口稳定性，通常前端需要和对应岗位的同学共建。
总结下来，我们一个稳定的前端项目，至少涉及到以下环节：
如果你所在的团队哪个环节还没有或者不完善，那么这也是你的机会。
作为一名前端工程师，陆陆续续负责了不少项目，这些项目中，有一些是正在迭代的，其他同事同时在负责的项目，但是也有不少项目，要么就是老旧项目维护的同事已经离职或转岗了的，要么就是新项目从 0 开始的，再加上前端代码积累速度和迭代速度都比较快，其中暴露了不少问题。
我身边的大多数程序员都有一个特点，就是喜欢把具体的东西抽象化，我们通常会抽象出公共的函数或方法、公共的类或HOC，放在一起，集中在项目的某一个文件夹下，叫做 js 文件夹或 lib 文件夹（以下我们用 js 文件夹代表公共函数文件夹 ）。
这样做的确带来了很多便利，但同时也有一些隐患：
WebAssembly 出现有很长时间了，但是由于日常工作并无直接接触，因此一直疏于尝试，最近终于利用一些业余时间简单入门了一下，因此在此总结。
首先我们需要知道 WebAssembly 是一个什么东西，其实际是一个字节码编码方式，比较接近机器码（但是又无法直接执行），这样可以方便地做到跨平台同时省去像 JavaScript 等语言的解释时间，所以是有一定优势的，使用起来其实也比较灵活，凡是可以转化成字节码的，都是可以使用 WebAssembly。
本文会对目前流行的基于 JavaScript 的 web 跨端融合方案进行总结和分析，目标人群为 web 方向的从业者但是对跨端融合方案了解不多的人。
在 2015 年 React Native 发布之前，web 在移动端 APP 上主要通过 WebView 进行承载，其有许多优点，可以快速迭代发布，不特别受 APP 版本的影响，因此，一些快速发展的业务（包括前期的手机QQ、手机淘宝）大量采用了 WebView 内嵌 H5 页面的形式来推动业务。
但是这种方式缺点也比较明显，主要体现在以下两点：
在 2015 年，Facebook 推出了 React Native，从而打开了 web 跨端融合的大门，后续在此架构基础上又出现了阿里巴巴的 Weex（2016）、腾讯的小程序（小程序实际上更偏 web 一点，和其他几类稍有不同，本文不作介绍）、 Hippy（2018）、Taro（Taro 其实更偏向解释翻译，和其他几类定位不同）等跨端融合解决方案，并且渐渐被用到越来越多的项目中，目前，跨端融合开发已经是一种比较主流的 web 开发模式，在阿里系应用、腾讯的微信、QQ浏览器、手机QQ均已经进行了大规模应用。
在 Node.js 的微服务中，一般不同的服务模块我们会采用 TCP 进行通信，本文来简单谈一谈如何设计 TCP 服务的基础管理。
本文主要对多组件单页面列表应用的代码组织实践进行总结，从而给相关应用的 Web 开发提供参考。
目前，其实多组件单页面列表应用非常常见，也是我们日常生活中使用非常高频的一个类别的应用，最典型的比如新闻信息流产品腾讯新闻、今日头条等这类新闻应用，在这类新闻应用中，往往图片、图文、视频、问答、投票等多种模块混杂排列。再简单一点的话，知乎、豆瓣甚至一些论坛以及一些购物软件，也可以归为此类应用。
首先描述一下笔者遇到的问题，我们可以设定这样一个场景：现在有一个实时监控系统的开发需求，要求同时支持多个用户（这里我们为了简化，暂时不涉及登陆态，假定一个设备即为一个用户），对于不同的用户来讲，他们需要监控的一部分内容是完全相同的，比如设备的 CPU 信息、内存信息等，而另外一部分内容是部分用户重叠的，比如对某一区域的用户来说某些监控信息是相同的，而还有一些信息，则是用户之间完全不同的。
对于每个用户来讲，当其进入页面之后即表明其开始监控，需要持续地进行数据更新，而当其退出界面或者手动点击停止监控，则停止监控。
raven.js 是 sentry 为 JavaScript 错误上报提供的 JS-SDK，本篇我们基于其源代码对其原理进行分析，本篇文章只分析前端部分，对应的文件目录是https://github.com/getsentry/sentry-javascript/tree/master/packages/raven-js。
首先抛出几个问题：