由于清洗数据的时候郑博士想要知道数据在年报原文中的出处，我不得不把数据校验器的搜索功能搞得越来越复杂。

由于清洗数据的时候郑博士觉得原文搜索功能很卡，我不得不把搜索功能搞到了 webworker （另一个线程）里去计算。

（为使 webpack 配置趋简，worker 文件里最好不要出现类型标注，但可以在 worker 文件引用的文件里自由使用类型标注，因为在我的配置里 .worker.js 文件会被 worker-loader 加载，这个优先级比较高，而 .js 文件则会被 babel-loader 加载。）

清洗数据的时候郑博士觉得原文搜索做得不错了，没以前那么卡，他指导我准备把原文搜索放到后端去做，因为每次搜索还是会卡一秒半这样，作为一个 Lucene 使用者他简直恨铁不成钢：「在后端用 Lucene 会比这快几十倍！」

但我敏锐地注意到，问题没这么简单。

因为界面会卡！

这个界面卡不是一般的卡，它是慢。如果是搜索的速度不行，那计算发生在 webworker 里，是不会阻塞住界面的，所以人不会觉得「卡」，这时候准确的形容词应该是「慢」。

而现在界面被阻塞住了，说明是主线程这边有问题，跑一个 Performance 看看：

都卡在 dispatch 这行：

我使用的数据层框架是 redux，它类似一个总线，让前端能实现命令查询职责分离，每个数据 API 请求都会把一个形似 { type: 'loadData/trigger' } 的 action 发送到总线里，这个用来发送 action 的函数叫 dispatch，然后被某个等待这个 action 的协程接收到。

webworker 是前端的多线程模型，我把它包装成了 redux 的一个插件 WorkerMiddleware。