async/await命名规范核心是让调用方一眼识别异步操作并预判返回值与副作用：推荐fetchUser、loadConfig等隐含异步的动词，必要时加Async后缀；变量名需体现Promise语义如userPromise；工厂方法用createWithAuth等明确创建+异步；错误处理命名如tryFetchAvatar需暴露失败可能性。
在大型单页应用（SPA）中，async 与 await 的命名规范不是语法强制要求，而是团队协作和长期可维护性的关键细节。命名本身不改变行为，但直接影响代码可读性、调试效率和新人上手成本。核心原则是：**让调用方一眼识别“这是异步操作”，并预判其返回值类型与副作用。**
方法名必须体现异步语义
避免使用同步风格动词（如 get、load、fetch 单独出现），而应组合明确的异步标识：
- ✅ 推荐前缀：
fetchUser、loadConfig、submitForm、validateEmail—— 动词本身已隐含网络或耗时操作，无需额外加Async - ✅ 明确标注场景：
initAppAsync（初始化类方法）、saveToStorageAsync（本地存储写入）—— 仅在易混淆时补充Async - ❌ 避免模糊命名：
getUser（无法区分是缓存同步取值还是发请求）、getData（完全无上下文）、handleClick（未体现内部是否 await）
返回值命名需与 Promise 类型对齐
async 方法必然返回 Promise，变量/参数命名应反映这一点，尤其在解构、类型注解或文档中：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- ✅ 声明时用
Pending/Result后缀：const userPromise = fetchUser(123)、const orderResult = await submitOrder() - ✅ TypeScript 中显式标注：
async function fetchProfile(): Promise<Profile> { ... }，而非any或省略 - ❌ 混淆同步语义：
const userData = fetchUser(123)（实际是 Promise，但变量名暗示是数据）
工厂方法与构造逻辑统一命名风格
因 constructor 不可 async，大型 SPA 常依赖工厂方法创建带异步初始化的实例。这类方法命名需突出“创建+异步”双重含义：
立即学习“Java免费学习笔记（深入）”；
- ✅ 清晰表达意图：
ApiClient.createWithAuth()、Router.initWithRoutes()、Store.hydrateFromServer() - ✅ 避免歧义：
new ApiClient()后必须手动await client.init()？不如直接提供ApiClient.create()并注明返回Promise<ApiClient> - ✅ 在 JSDoc 中明确标注：
/** @returns {Promise<AppState>} */，比命名更可靠，但命名是第一道提示
错误处理相关命名要暴露失败可能性
async 方法一旦抛错，调用链可能中断。命名可辅助提醒开发者注意容错：
- ✅ 区分安全与非安全操作：
tryFetchAvatar()（内部吞错并返回 null）、requireUserProfile()（预期必成功，失败即 crash） - ✅ 避免误导性乐观命名：
getValidToken()（若 token 过期会 throw，但名字没提示风险）→ 改为acquireToken()或refreshToken() - ✅ 在 hooks 或 Vue composables 中，常用
useXxxQuery（如useUserQuery）已成约定，隐含返回{ data, isLoading, error }状态对象，不需额外加 Async
