Ответ 1
Все зависит от того, что вы делаете в функции обратного вызова. Если вам нужно убедиться, что обратный вызов еще не запущен, когда get возвращается, вам понадобится поток process.nextTick; во многих случаях вам все равно, когда срабатывает обратный вызов, поэтому вам не нужно задерживать его выполнение. Невозможно дать окончательный ответ, который будет применяться во всех ситуациях; должно быть безопасно всегда откладывать обратный вызов на следующий тик, но он, вероятно, будет немного менее эффективным таким образом, поэтому это компромисс.
Единственная ситуация, в которой я могу подумать, где вам нужно отложить обратный вызов для следующего тика, - это то, что вам действительно нужно что-то установить для него после вызова get, но до вызова callback. Это, пожалуй, редкая ситуация, которая также может указывать на необходимость улучшения фактического потока управления; вам не следует полагаться вообще на то, когда вы вызываете именно ваш callback, поэтому любая среда, в которой он используется, уже должна быть настроена в точке, где вызывается get.
В потоке управления на основе событий (в отличие от callback-based) есть ситуации, когда вам может потребоваться отсрочка фактического срабатывания. Например:
function doSomething() {
var emitter = new EventEmitter();
cached = findCachedResultSomehow();
if (cached) {
process.nextTick(function() {
emitter.emit('done', cached);
});
} else {
asyncGetResult(function(result) {
emitter.emit('done', result);
});
}
return emitter;
}
В этом случае вам нужно будет отложить выброс в случае кешированного значения, поскольку в противном случае событие будет выдано до того, как вызывающий doSomething имел возможность подключить прослушиватель. Обычно вы не рассматриваете это при использовании обратных вызовов.