抱歉，直言不讳，但这里有很多错误。
readFile在调用回调之前，将文件的
全部内容 读取到内存中，此时您开始上载文件。
这很不好-特别是在处理图像之类的大文件时-因为实际上没有理由将文件读入内存。这很浪费；在负载下，您会发现服务器的内存不足并崩溃。
相反，您想获得一个 stream
，当从磁盘读取数据时会发出大块数据。您要做的就是将这些块传递到您的上传流（
pipe），然后从内存中丢弃数据。这样，您永远不会使用过多的缓冲存储器。
（可读流的默认行为是处理原始二进制数据；仅当您传递时
encoding，它才以文本进行处理。）
该请求模块使得该特别容易：
fs.createReadStream('test.png').pipe(request.post('http://0.0.0.0:5000/'));在服务器上，您遇到了更大的问题。 切勿使用*Sync
方法。 它将阻止您的服务器执行 任何操作
（例如响应其他请求），直到将整个文件刷新到磁盘为止，这可能需要几秒钟的时间。
因此，我们要获取传入的数据流并将其通过管道传输到文件系统流。您本来是在正确的轨道上；没用的原因
req.body.pipe(fs.createWriteStream('test.png'))是因为body它不是流。
body由
bodyParser中间件生成。在Restify中，该中间件的行为很像
readFile，它在内存中缓冲了整个传入的请求实体。在这种情况下，我们不想要那样。禁用主体解析器中间件。
那么传入数据流在哪里？它是
req对象本身。restify的
Request继承节点的
http.IncomingMessage，这是可读流。所以：
fs.createWriteStream('test.png').pipe(req);我还应该提到，所有这些工作之所以如此简单，是因为不涉及任何形式的解析开销。请求仅发送没有
multipart/form-data包装的文件：
POST / HTTP/1.1host: localhost:5000content-type: application/octet-streamConnection: keep-aliveTransfer-Encoding: chunked<image data>...
这意味着浏览器无法将文件发布到该URL。如果需要，请查看formidable，它可以对请求实体进行流解析。
