async useEffect回调是真有害还是仅属于代码坏味道？

很多技术文章都会建议不要直接给useEffect传入async函数作为回调，也就是不推荐下面这种写法：

useEffect(async() => {
  await doSomethingAsynchronous();
})

而是建议把异步逻辑定义在effect内部再调用：

useEffect(() => {
  const asyncAction = async () => {
      await doSomethingAsynchronous();
  };
  asyncAction();
})

你提到的认知基本是对的：两种写法下，异步函数生成的Promise都会被React忽略，React本身不会等待异步逻辑执行完成，ESLint规则的初始告警原因也确实是这种写法容易误导开发者，让人误以为React会等待异步流程结束。
你总结的两个功能限制也是真实存在的：

• async函数的返回值永远是Promise，而useEffect约定回调的返回值必须是清理函数，直接传async回调的话，就算你在函数内部return了清理逻辑，也会被Promise包裹，React识别不到，永远不会执行
• 直接传入async回调时，异步逻辑抛出的未捕获错误会直接变成全局的未处理Promise拒绝，你没法在effect回调的外层统一挂载错误处理，当然你可以在async函数内部写try/catch，但灵活度会低很多

针对你最关心的问题：如果业务场景完全不需要清理逻辑，也能保证在异步函数内部做好所有错误捕获，第一种写法会不会引发实际的运行故障？
在当前所有已发布的React稳定版本中，答案是不会。React对effect回调返回值的处理逻辑非常简单：如果返回值是函数类型，就存为该effect的清理函数，在组件卸载/依赖更新时执行；如果不是函数类型，直接忽略返回值。你传入async回调返回的Promise，只会被React当成普通非函数值丢掉，不会影响异步逻辑本身的执行，也不会直接造成崩溃、性能问题或者逻辑错误。

但这并不代表这种写法是值得推荐的，它和你提到的() => 5这类单行箭头函数简写有本质区别：

• 单行箭头函数简写的语义是完全明确的，所有开发者看到都能立刻知道这段代码就是要返回值5，没有隐含歧义，后续需要扩展逻辑时，重构也不会出现语义偏差
• 直接给useEffect传async回调的写法本身是违反API约定的，React官方从来没有承诺过支持传入返回Promise的effect回调，这种写法本质是在依赖React当前版本的内部实现细节，未来React如果在开发环境加校验、对effect返回值做更严格的处理，这种写法可能会直接报错
• 这种写法会提升代码的维护成本：任何第一次接触这段代码的开发者，第一反应都会怀疑写代码的人是不是不了解useEffect的机制，是不是漏了清理逻辑、错误处理；更麻烦的是需求迭代的隐患——你今天写代码时确定不需要清理、不需要额外错误处理，但过两周需求变更，需要给异步请求加取消逻辑、加竞态判断、加卸载时的状态重置，如果你已经习惯了直接写async回调的形式，很容易忘记这种写法返回的Promise会让清理函数失效，最后写出的清理逻辑根本不执行，引发内存泄漏、组件卸载后更新状态的警告、竞态导致的错误数据渲染等问题，这类问题往往是偶现的，排查成本很高。

简单说：这种写法不是「写了立刻就炸」的致命错误，但它是一个会给未来埋坑的坏实践，投入几乎为零的成本改成内部定义异步函数的写法，就能彻底规避这些隐患，完全没必要为了少写几行代码冒这个风险。

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