给非异步操作添加async/await是否属于不良编程规范？

不算绝对的不良实践，但这种做法存在明确的利弊取舍，得结合你的代码库场景判断：

支持统一async的合理出发点 #

• 降低心智负担：在异步为主的代码库里，所有函数都返回Promise，调用时统一用await，不用再纠结“这个函数到底是同步还是异步”，彻底避免因遗忘加await导致的异步逻辑错误。
• 接口一致性：同个类或模块里的函数调用方式统一，后续如果同步函数需要改成异步（比如未来要加远程校验），不用修改所有调用处的代码，兼容性更好。

这种做法的潜在问题 #

• 性能损耗：async函数本质会把返回值包装成Promise，即使是纯同步逻辑，也会触发微任务调度。单次调用的开销很小，但如果这类同步函数被高频调用（比如循环里多次执行字符串校验），累积的性能成本会显现。
• 语义混淆：async关键字的语义是“此函数包含异步操作”，纯同步逻辑套async会误导其他开发者，让他们误以为函数内部有IO/API调用，增加代码理解成本。
• 调试复杂度：Promise的调用栈比同步函数多一层包装，当这类函数出现问题时，调试时的调用栈会包含Promise相关的帧，增加排查难度。

更平衡的实践建议 #

1. 按场景区分处理
   • 如果是和异步强绑定的同步逻辑（比如作为异步流程中的前置校验步骤，只会在async函数里被调用），可以改成async，保持调用一致性。
   • 如果是通用工具类的纯同步函数（比如独立的字符串校验、数据格式化），建议保持同步。如果需要在异步流程中调用，用Promise.resolve(isValidLength(name))临时包装即可，不用修改函数本身。
2. 团队统一规范
   和团队约定明确的规则：比如哪些模块允许全async，哪些必须保留同步函数，避免个人习惯导致的代码风格混乱。

举个例子，你的同步校验函数可以保持原本的同步写法：

static isValidLength(name){
    return name.length > 5;
}

如果需要在异步流程中使用，只需要这样调用：

async function checkName(name) {
    const isValid = await Promise.resolve(isValidLength(name));
    // 后续异步逻辑
}

内容的提问来源于stack exchange，提问作者ConfusedStudent