为何JavaScript顶层允许使用await但普通函数内却不行？这种设计的意义是什么？

这确实是个容易让人摸不着头脑的设计点，我来给你拆解清楚～

首先得明确：顶层await和普通函数内不能用await，本质是为了维护JavaScript异步模型的一致性和避免意外的行为。

你提到希望普通函数里能用await来实现阻塞效果，但JavaScript的核心设计理念之一就是「非阻塞异步」——单线程的JS要是随便允许函数阻塞，很容易导致整个页面/进程卡死，这显然不是语言设计者想看到的。

先看你给出的顶层await例子：

function sleep(ms) {
    return new Promise((resolve) => {
        setTimeout(resolve, ms);
    });
}

// works
print("bef");
await sleep(1000); // blocking
print("aft");

async function asyncsleep(ms) {
    return new Promise((resolve) => {
        setTimeout(resolve, ms);
    });
}

// works
print("bef");
await asyncsleep(1000); // blocking
print("aft");

这里的顶层await是在模块上下文中运行的，它的“阻塞”只是让当前模块的加载流程暂停，等待异步操作完成后再继续导出内容，并不会卡死整个JS的事件循环——浏览器/Node的其他任务还是能正常执行的。这是后来ES模块引入顶层await的核心原因：方便处理模块的异步初始化逻辑，比如加载远程数据后再导出模块内容。

那为什么普通函数里不能直接用await呢？

• 首先，传统的普通函数都是同步执行的，调用后会立即返回结果。如果允许普通函数里用await，这个函数的行为就会突然变成异步，但它的返回值又不是Promise（不像async函数会自动包装返回值），这会造成逻辑混乱——调用者根本不知道这个函数会“偷偷”阻塞，也没法处理异步结果。
• 其次，显式标记async函数是一种「自我说明」：看到async关键字，开发者就立刻明白这个函数是异步的，会返回Promise，调用时需要用await或者.then()来处理结果。这种显式的设计能减少代码的歧义，避免意外的bug。

如果你真的需要类似“阻塞”的同步效果，其实应该把函数声明为async，然后调用时用await，或者在Node.js里用一些特殊的同步API（但不推荐，因为会阻塞事件循环）。JavaScript的异步模型就是鼓励你用非阻塞的方式处理异步逻辑，而不是回到同步阻塞的老路子上～

备注：内容来源于stack exchange，提问作者Someone