一次TS类型推断bug处理的思考

在使用await-to-js这个库的时候，发现了一个类型问题，代码 & 问题如下图：

async login(loginForm: LoginData) {
        const [err, res] = await login(loginForm);

        if (err) {
            clearToken();
        }
        setToken(res.data.jsesessionid);
}

附上await-to-js的类型定义

declare function to<T, U = Error>(promise: Promise<T>, errorExt?: object): Promise<[U, undefined] | [null, T]>;

很奇怪，这里我期望的是，TS能自动推断出下面setToken代码这里，类型为 [null, T]这个子项，这样res类型为 T 必然存在。

但是TS报错了，TS表示，你这里的 res 任然是联合类型 T | undefined，我百思不得其解，为啥TS没推断出来...

于是在群里开水了

发出去后，可能自己提问的描述有点绕，暂时无人回答，经过了1分钟的快速思考，我换了一种编码方式

async login(loginForm: LoginData) {
            const [err, res] = await login(loginForm);

            if (!err) {
                setToken(res.data.jsesessionid);
            }
            clearToken();
},

欸，此时没问题了，TS能够正常推断出 res 类型为 AxiosResponse<LoginRes, any> 了。不过此时我还没意识到问题的根源在哪里（迷糊中...）

于是我想，这么看来，这TS类型推断只能反着来？于是我大言不惭的在群里开始结帖，欸，这一定是TS的问题，它推断不出来。

不过，万幸的是，很快哈，牛批的群友立马指出了错误，为TS洗刷了冤屈。

我真傻，真的，我单知道TS能够通过类型保护自动推断类型，我不知道，我的if没有else，也没有return。TS是很听话的，我的setToken放在没有if return的下面，它就知道了，这里还是 T | undefined，我还在傻傻的找TS的问题，找来找去，却是看见大佬的一句“你的if没有return”。我心想，糟了，怕是我错怪了人家，我修改了代码，再近近一看，它果然不报错了......

真正的结帖

TS类型推断肥肠智能，当我们用 if(err)对err进行类型保护后，在else 或if return 后的语句，TS能够自动推断出，这里的err类型为null，那么res自然就是T了。

PS：有群友发出了跟我一样的疑问

一次粗心的经历，让我对TS的认识加深了，await-to-js 听我说谢谢你......