process.send在Node.js中有条件地定义

无论出于何种原因，在Node.js中，函数process.send在某些环境中定义，但在其他环境中未定义。例如，当我在Node.js中从父进程派生子进程时，如下所示：

//parent process
var cp = require('child_process');
var k = cp.fork('./child.js',['arg1','arg2','arg3']);
k.send('fail'); //k.send is defined...
process.send("ok, let's try this..."); //process.send is NOT defined

在子进程内部：

//child.js
process.send('message');  //process.send is defined, and will send a message to the parent process above

为什么在某些Node.js进程中有条件地定义了

process.send

，而在其他进程中没有？Node.js架构师的设计决策似乎很糟糕

我知道如何绕过这个问题的唯一方法是：

if(typeof process.send === 'function'){ 
process.send('what I want to send')
});

---

子进程有一个

进程。send

方法与产生它们的进程通信，而根进程没有任何“父进程”进行通信，因此它不在那里。从：

在子进程中，进程对象将有一个send（）方法，进程每次在其通道上接收消息时都会发出对象

为了避免“在代码中添加条件”，一个临时解决方案可能是将一个“noop”函数放在任何可能从中生成进程的“根”文件的顶部：

process.send = process.send || function () {};

---

Sapper&Svelte使用的变通方法：

基本上，当您在环境中提供SAPPER_导出变量时，此错误可以在流中接收

---

关于这个问题的更多细节：

你的意思可能是

k.send（'fail'）？是的，谢谢你是对的如果你的意思与问题状态不同，那么请编辑你的问题以更正它。这个问题非常清楚，不值得任何形式的否决票。这在我看来是非常蹩脚的。所有进程都应该有一个父进程。如果没有人在听，send不应该做任何事情，就像其他发布/子类型API一样。但没关系，我们可以在代码中添加条件，正如我在编辑OPYeah时提到的，这可能是有原因的。现在你可以把
process.send=process.send | |函数（）{}在你的“根”文件的开头。谢谢McMillan先生，你似乎明白了。您的解决方案看起来并不比任何其他解决方案更糟。这是一个令人讨厌的问题。我希望这有一个很好的理由…如果你在代码中“乱扔”了条件，那么可能是出了问题。在设计良好的系统中，父/子进程通常只共享很少的代码。@当然
process.send
使用JSON over IPC fd机制，该机制完全特定于节点。使用它来尝试向非节点进程发送消息是没有意义的。那么为什么不将其默认为no op呢？因为使一个有意义的命名方法成为一个不可操作的方法是灾难性的不可发现和混乱的。正如这个答案所表明的，你可以很容易地把它变成一个不可操作的东西，而事实并非如此（当它的唯一影响是在另一个过程中时，你如何确定它是一个不可操作的东西？）。