直接传递process.stdout.write与通过回调传递为何输出不同？

你猜的完全没错，核心问题确实和this的指向有关，和缓冲关系不大。咱们来拆解两种写法的本质区别：

1. 两种写法的this绑定差异 #

• 你的原始写法（箭头函数）：

  ls.stdout.on("data", (data) => {process.stdout.write(data)});
  

  箭头函数不会创建自己的this上下文，它会继承外层作用域的this。这里你明确通过process.stdout.write调用，相当于把write函数的this硬绑定到了process.stdout对象上，内部逻辑能正常执行。

• 重构后的写法（直接传函数）：

  ls.stdout.on("data", process.stdout.write);
  

  Node.js的EventEmitter在触发回调时，会自动把回调函数的this绑定到触发事件的Emitter实例上——也就是这里的ls.stdout，而不是原来的process.stdout。

2. 为什么会出现无输出或EPIPE错误？ #

process.stdout.write这个方法的内部逻辑严重依赖this指向自身（process.stdout），比如要操作对应的文件描述符、管理输出缓冲、处理流的状态等。当this被错误绑定到ls.stdout后：

• 如果ls.stdout是一个不支持写入操作的流（它本身是可读流），写入操作会静默失败，导致无输出；
• 如果底层文件描述符已经被关闭（比如父进程的stdout提前终止），错误的写入操作会触发EPIPE错误（管道断裂，因为试图向一个已关闭的写端写入数据）。

3. 修复方案 #

有两种简单的方式解决这个问题：

• 方案一：用bind固定this指向
  手动把write函数的this绑定到process.stdout，确保回调执行时上下文正确：

  ls.stdout.on("data", process.stdout.write.bind(process.stdout));
  

• 方案二：保留箭头函数包裹
  继续用你最开始的箭头函数写法，这种方式更直观，也能避免this绑定的坑，代码可读性更高。

内容的提问来源于stack exchange，提问作者rb612