我是不是发现了Node.JS一个缺点？是否可以优化？

Question

Node.JS 以下简称 node。
node 中的 async 和 await 各位都不陌生吧？普通的 function 和 async function 有什么区别 我相信大家也知道，如果你不知道，请看这篇文章 https://blog.csdn.net/ScumStu...

看到第1.3章节即可，记住 async 函数返回的是一个 Promise 对象。

背景：一个大型项目A，也许还有其它部门项目和它耦合，这时A项目的 c 函数，往 if 判断里加一个异步请求。

那么问题就来了

这时要么使用回调的方式，把 if 块里的代码放到回调里，并把 if 块外的代码也放进去，并在回调结尾处执行 return；
把 c 函数变为 async 函数，c 函数此时变成了一个 Promise，所有调用 c 函数的函数为了能同步调用 c 函数也变成了 async 函数。
按照第二步接着说，假如 a、b 函数为了同步调用 c 函数变成了 async 函数，那么所有调用 a、b 函数的函数也要变成 async 函数。
浏览器中 js 写起来也一样

我思索了良久，有了上面这个想法后，我就想：我在干什么？怎么工作难度成指数级增长了，写 node 语言的团队难道不知道这个问题？谷歌难道不知道这个问题？

Answer 1

可以使用发布订阅等模式将逻辑分层，中断异步的传染性。

以 vue 开发为例，参考：在前端开发中如何消除异步的传染性？

Answer 2

是的，所以 async/awiat 会有污染的问题。

Answer 3

那么，为什么要在if里面放一个异步的请求呢？能否修改代码组织方式来避免这个问题？

Answer 4

其实是这么一个问题吧？

function c (data) {
    return data + '模拟操作'
}

const res = c()

这个时候向里面增加了一个异步操作，变成这样（导致不得不去重构c方法，以及所有使用到c的地方）

async function c (data) {
    // 第一种
    const config = await getConfig()

    // 第二种
    getConfig().then(function (res) {
        // 这里就必须使用回调了
        callback('处理后的数据')
    })
    return data + '模拟操作' + config
}

const res = await c()

这在js中没法避免，我个人也觉得有点烦，除非所有function 默认支持同步操作

Answer 5

异步带传染性，这不仅是语言特性。

现实生活中也是如此。

Answer 6

只要不在全局作用域或模块作用域使用 await ，就没什么问题。
async 函数的返回值是 Promise，你完全可以使用回调函数的方式来处理 Promise所“承诺”的值——那么如果你以为的那种缺陷无法避免，同样回调函数也无法避免，整个 JS 的大厦就轰然倒塌了。
所以你该不会是没学懂 Promise 吧😒

Answer 7

对外的接口默认提供同步的function，是否需要async 由调用方决定。或者同时提供sync和async的版本