为什么Node.js中的某些同步库坚持使用回调？

如何解决为什么Node.js中的某些同步库坚持使用回调？

| 我是一个新的nodejs开发人员，我认为我了解nodejs的设计。我可以理解，一些与syscall相关的库应该是异步的。这些作业将在不同的线程池中排队和处理，并在完成时通过回调通知。但是，我不明白为什么某些非系统调用相关的库将回调用作通信方法。例如，xml2js库是用Javascript编写的，显然，没有理由使此解析函数通过回调返回状态。它可以直接返回处理结果，并提高了代码的可读性。我的问题是，是否有某些原因使某些nodejs库设计人员坚持基于回调的通信，而不只是使用返回值？

解决方法

回调样式没有错。

var return = doSomething();
...

doSomething(function(return) {
    ...
});

这是首选项。它们都是有效的。前者看起来“比较好”，因为您已经习惯了。后者的一个好理由是，当您将库更改为非阻塞时，无需更改API。需要提醒人们的是，节点是一个底层的无阻塞IO库。如果您要执行类似js2xml的操作，那么显然您正在等待节点0.6标准化Web Worker子流程API，以便您可以将繁重的工作发送给子流程，并在不阻塞的情况下进行实际的工作时尚。为此，您的API必须是异步的（或者您需要将其内置到语言中）。 ,如果它不是异步的，则没有理由使用回调传递返回值。我已经看到一些库使用回调而不是返回来只是将错误传回，尽管我认为使用throws更好，更清洁。 ,实际上就LibXML解析器实现而言。您确定从未发生过系统级IO吗？考虑一下您解析的XML包含DTD或Schema的情况。 XInclude处理通常在XML解析器中完成。尽管没有根本原因，但要有一个不使用任何低级IO功能来使用async-callback样式的API，您并不总是知道是否确实没有发生IO的情况。现在假设您知道XML-Parser不执行任何IO，因为它不处理XInclude和DTD / Schema验证。因此，如果您决定采用“传统”返回值路线，那么在不更改API的情况下，您将永远无法实现XInclude处理或架构验证。通常，如果您正在编写API，则最好从一开始就进行异步/回调，因为您永远不知道以后要做什么。 ,回调在各种情况下都很有用，例如，当您遍历某个集合（出于某种原因而被封装）时：

function Foo() {
    this._data = [1,2,3,4,5]; 
}

Foo.prototype.forEach = function(callback) {
    var i,len = this._data.length;

    for(i = 0; i < len; i++) {
        callback(\"Item number: \" + this._data[i]);
    }
}

var foo = new Foo();

foo.forEach(function(item) {
    console.log(item);
});