我有一个非常简单的模块，它包装了“fs”模块。该模块简单地“承诺”所有“fs”方法并导出新对象：
fsWrapper.ts
import Promise from "bluebird";
import * as fs from "fs";
const fsWrapper = Promise.promisifyAll(fs);
export = fsWrapper;
现在我可以使用这个包装器而不是在每个调用者模块中“promisifiying”“fs”模块，如下所示：
主文件
import fsWrapper from "./fsWrapper";
function test(): void {
fsWrapper.readFileAsync("tst.txt", "utf8")
.then((data: Buffer) => {
console.log("data:", data.toString());
})
}
这当然不适用于打字稿，因为“fs”不包含该readFileAsync方法并且我收到编译器错误。
在寻找正确键入此包装器的方法时，我发现了以下打字稿问题。
使用它的方法，我可以创建自己的fsWrapper.d.ts，其中需要手动添加 *Async 方法，类似于以下内容：
fsWrapper.d.ts
import Promise from "bluebird";
declare module "fs" {
export function readFileAsync(path: string, options: { encoding?: string | null; flag?: string; } | string | undefined | null) : Promise<Buffer>; …我正在使用一个非常简单的 redis pub-sub 应用程序，其中我在 AWS 中有一个 redis 服务器和一个基于 nodejs 的 redis 客户端，该客户端位于订阅某个频道的办公室局域网内。
这很有效，直到网络发生变化，并且似乎某些设备现在正在干扰传出连接（我也开始接收出站 SSH 连接上的套接字挂断，我通过ServerAliveInterval 60SSH 配置中的设置缓解了这种情况）。
在网络发生变化后，每当 redis 客户端应用程序被执行时，它都会创建一个 redis 客户端，订阅某个频道并对在该频道中发布的消息进行操作。它可以正常工作几分钟，但随后它停止接收任何消息。
我将 redis 客户端注册到所有已知的连接事件（包括“错误”事件），我添加了一个“retry_strategy”处理程序，并将配置修改为“socket_keepalive”和“socket_initialdelay”为 10 秒（见下面的代码）。
然而，当连接受到干扰时不会触发任何事件。
当应用程序停止接收消息时，我看到 redis 端口上的连接仍然有效：
dev@server:~> sudo netstat -tlnpua | grep 6379
tcp 0 0 10.43.22.150:52052 <server_ip>:6379 ESTABLISHED 27014/node
我还在端口 6379 上捕获了一个 PCAP，在该端口上我没有看到任何重置或 TCP 错误，而且从连接的角度来看，一切似乎都是有效的。
我尝试从 LAN 中运行另一个 nodejs 应用程序，在其中我创建了一个连接到 AWS redis 服务器的客户端，注册到所有事件并且只偶尔发布一次消息。几分钟后（连接中断），我尝试发布另一个命令，并且确实触发了错误事件处理程序：
> client.publish("channel", "ANOTHER TRY")
true
> Error: Redis connection to <server_hostname>:6379 failed - read ECONNRESET
Redis connection …