根据您的用例，您可以使用类似

简化的界面，让CPU密集型代码运行在所有核心(node.js和web)

一个例子是

function blocking (exampleArgument) {
    // block thread
}

// turn blocking pure function into a worker task
const blockingAsync = task.wrap(blocking);

// run task on a autoscaling worker pool
blockingAsync('exampleArgumentValue').then(result => {
    // do something with result
});

所以我认为我们现在有了另一个很酷的选择，这要感谢ES6中的模板文字。这允许我们省去额外的worker函数(及其奇怪的作用域)，只需将用于worker的代码编写为多行文本，就像我们用来存储文本的情况一样，但实际上不需要使用文档或DOM来实现。例子:

const workerScript = `
self.addEventListener('message', function(e) {
  var data = e.data;
  console.log('worker recieved: ',data);
  self.postMessage('worker added! :'+ addOne(data.value));
  self.close();//kills the worker
}, false);
`;

下面是该方法的其余要点。

请注意，我们可以将任何我们想要的额外函数依赖项拉入worker，只需将它们收集到一个数组中，并对每个函数运行. tostring，将它们简化为字符串(只要它们是函数声明就可以工作)，然后将其添加到脚本字符串中。这样，我们就不必导入我们可能已经捆绑到正在编写的代码范围中的脚本。

这个特定版本唯一的缺点是lints无法检测service worker代码(因为它只是一个字符串)，这对于“单独的worker函数方法”来说是一个优势。

网络工作者在完全独立的上下文中操作，就像单个程序一样。

这意味着代码不能以对象的形式从一个上下文中移动到另一个上下文中，因为它们可以通过属于另一个上下文中的闭包引用对象。 这一点尤其重要，因为ECMAScript被设计成一种单线程语言，并且由于web worker在单独的线程中操作，那么您将有执行非线程安全操作的风险。

这再次意味着web工作者需要用源代码形式的代码进行初始化。

WHATWG的规格说明说

如果原点的结果 绝对URL是不一样的 输入脚本的起源，然后抛出 SECURITY_ERR异常。 因此，脚本必须是外部文件 和原来一样的方案 页面:您无法从 data: URL或javascript: URL，和一个 页面无法启动工作 使用http: url脚本。

但不幸的是，它并没有真正解释为什么不允许将带有源代码的字符串传递给构造函数。

您可以创建一个JavaScript文件，该文件可以感知其执行上下文，并且可以充当父脚本和工作脚本。让我们从这样一个文件的基本结构开始:

(function(global) {
    var is_worker = !this.document;
    var script_path = is_worker ? null : (function() {
        // append random number and time to ID
        var id = (Math.random()+''+(+new Date)).substring(2);
        document.write('<script id="wts' + id + '"></script>');
        return document.getElementById('wts' + id).
            previousSibling.src;
    })();
    function msg_parent(e) {
        // event handler for parent -> worker messages
    }
    function msg_worker(e) {
        // event handler for worker -> parent messages
    }
    function new_worker() {
        var w = new Worker(script_path);
        w.addEventListener('message', msg_worker, false);
        return w;
    }
    if (is_worker)
        global.addEventListener('message', msg_parent, false);

    // put the rest of your library here
    // to spawn a worker, use new_worker()
})(this);

如您所见，脚本包含父进程和工作者进程的所有代码，检查它自己的实例是否是一个具有!document的工作者进程。有点笨拙的script_path计算用于精确计算相对于父页的脚本路径，因为提供给新Worker的路径是相对于父页的，而不是相对于脚本的。

我认为更好的方法是使用Blob对象，下面你可以看到一个简单的例子。

// create a Blob object with a worker code
var blob = new Blob(["onmessage = function(e) { postMessage('msg from worker'); }"]);

// Obtain a blob URL reference to our worker 'file'.
var blobURL = window.URL.createObjectURL(blob);

// create a Worker
var worker = new Worker(blobURL);
worker.onmessage = function(e) {
  console.log(e.data);
};
worker.postMessage("Send some Data"); 

@Trincot's似乎是目前为止最好的。然而，也许我们可以进一步发展它。所以我的想法是，

我们不要修改Function.prototype。 为线程操作获取函数的承诺/线程化版本。 如果需要，请确保仍然可以同步调用该函数。

因此，我们用spawn方法定义了Threadable类。一旦我们将函数设为该类的成员，那么它就是可线程的:)

class Threadable extends Function { constructor(f){ super("...as",`return ${f.toString()}.apply(this,as)`); } spawn(...as){ var code = `self.onmessage = m => self.postMessage((${this.toString()}).apply(self,m.data));`, blob = new Blob([code], {type: "text/javascript"}), wrkr = new Worker(window.URL.createObjectURL(blob)); return new Promise( (v,x) => ( wrkr.onmessage = m => (v(m.data), wrkr.terminate()) , wrkr.onerror = e => (x(e.message), wrkr.terminate()) , wrkr.postMessage(as) ) ); } } function add(...nums) { return nums.reduce((a,b) => a+b); } var addT = new Threadable(add); addT.spawn(1,2,3,4) .then(m => console.log(`Promisified thread returned ${m}`)); console.log(`Synchronous invocation of addT returned ${addT(1,2,3,4)}`);