响应式变量命名需按类型分层：ref统一加Ref后缀（如searchQueryRef），reactive用单数名词+业务主体（如formState），禁用泛化词与语义错位命名。
变量命名不是“起个名字”那么简单，而是代码专业性的第一道门槛。在大型项目中，一个命名混乱的变量可能被多个模块引用、调试时反复猜意图、重构时不敢动——最终拖慢交付节奏、增加协作成本。真正有效的命名规范，要能让人一眼看懂作用域、类型、语义和状态，不依赖注释，也不靠上下文补全。
按类型分层：让 ref 和 reactive 一目了然
Vue 3 中 ref 和 reactive 行为差异大，混用容易出错。命名必须强制体现响应式类型：
-
ref 变量统一加 Ref 后缀：如 searchQueryRef、isSubmittingRef、userListRef。避免模板里误写
{{ searchQuery }}而漏掉.value导致渲染为空。 -
reactive 对象用单数名词 + 明确业务主体：如 formState（非
form或formData）、tableConfig、apiResponse。拒绝泛化词如data、info，否则无法判断其结构和用途。 -
禁止语义层级错位：不接受
userInfo（reactive）和userName（ref）并存；应统一为 currentUser（reactive），或仅当需独立更新时拆出 currentUserNameRef。
按作用域分级：明确变量归属与生命周期
大型项目常含多层组件、composable 和全局状态，命名前缀是快速定位的关键：
- 全局状态加 global 前缀：如 globalThemeRef、globalUserState。这类变量通常来自 Pinia store 或 provide/inject，前缀提醒“改它会影响整个应用”。
-
组合式函数内变量加 use 后缀标识来源：如 useFetchDataRef、useTableState。不是函数名，而是表明该变量由
useXXX()返回，便于调试时回溯逻辑链。 -
组件内局部变量不加前缀，但必须带业务动词或状态词：如 isMenuOpen、pendingAction、filteredItems。杜绝
temp、data1、flag等无意义命名。
绑定业务语义：用名字代替文档
变量名是代码的第一份文档。它必须自解释，尤其在跨组件、跨 hooks 使用时：
-
布尔型强制使用 is/has/can/should 开头：如 isDarkModeEnabled、hasPermission、canEditProfile。避免
darkMode、permission这类模糊表达。 -
异步状态用动词 + 名词 + 状态组合：如 fetchingUser（进行中）、fetchedUser（已完成）、fetchUserError（失败）。比
loading、success更具上下文。 -
派生数据体现计算逻辑：如 filteredProducts、sortedUsers、activeTabKey。不写
result或list，直接说明“是什么、怎么来的”。
配套落地工具：让规范不流于纸面
再好的规范，没有机制保障就容易失效。建议三件套同步上线：
- ESLint 插件定制规则：拦截无后缀 ref、非 is/has 布尔名、全局变量缺 global 前缀等典型问题，CI 阶段直接报错。
-
VS Code 代码片段（snippets）：预置
ref、reactive、globalRef等模板，输入缩写自动展开为合规命名 + 类型声明。 -
类型别名辅助语义固化：如
type UserFormState = ReturnType，配合命名形成双重约束，既保类型安全，又强化业务含义。;
