WebStorm 不支持自动将回调转为 async/await，无内置「Convert callback to async」功能；仅能手动替换调用、补 try/catch、处理 this 绑定，并依赖外部工具或插件实现安全重构。
WebStorm 本身不支持自动将回调转 async/await
它没有内置的「Convert callback to async」重构功能，也不会分析 fs.readFile 或 db.query 是否可 Promise 化。你看到的“Refactor → Convert to async”菜单项并不存在——这是常见误解。所有声称 WebStorm 能一键转回调为 async/await 的教程，实际都是手动操作或依赖插件（如第三方 AST 插件），官方从未提供该能力。
能做的只有基础语法替换 + 手动补全错误处理
如果你坚持在 WebStorm 里“半自动”处理，可行路径是：先用 Shift+F6 重命名回调函数名（比如把 handleUser 改成 handleUserAsync），再手动改写调用点。但注意：
- 不能只改函数名，
fs.readFile(path, cb)不会因为你把cb改名叫cbAsync就自动变成await fs.promises.readFile(path) - 必须手动替换原调用为
await fs.promises.readFile(path)，否则仍执行旧回调逻辑 -
try/catch块需手写，WebStorm 不会自动包裹；漏掉catch就等于放弃错误冒泡，和原来回调里if (err) return callback(err)行为不等价 - 若原回调用了
this或闭包变量，直接套async函数可能改变绑定，得检查是否需用箭头函数或显式.bind()
真正安全的重构必须绕过 WebStorm GUI
靠 IDE 点几下是搞不定的，原因很实在：
- WebStorm 的 AST 解析跳过
eval、setTimeout("...", 100)、动态 key（如obj[fnName]）里的回调，但这些地方恰恰容易藏回调地狱 - 它无法判断
api.login(u, cb)是否有对应api.loginAsync，也不会帮你加import { promisify } from 'util' - 对
this绑定、arguments、生成器内部回调等上下文敏感场景，GUI 无感知，强行转会导致运行时this指向undefined - 即使你用
Replace in Path批量把(err, res) =>替成async (err, res) =>，也毫无意义——async修饰的是函数本身，不是回调参数
最接近“自动化”的务实做法
用 Babel 插件（如 @babel/plugin-transform-async-to-generator 反向思路）配合自定义 AST 规则，但前提是：
- 代码已用标准错误优先回调模式（
(err, data)），且无动态构造 - 目标函数明确支持
.promises子模块或已promisify过 - 所有调用链都同步升级，不能只改一层而留着上层仍是
.then(() => {}) - 重构后必须跑通单元测试，尤其验证
throw是否真被外层catch捕获，而非静默吞掉
这一步没法靠 WebStorm 的 Rename 或 Extract Method 完成，它连 fs.promises.readFile 和 fs.readFile 的语义差异都识别不了。
