变量命名应精准表达逻辑与业务语境，避免依赖注释补救；优先用完整单词、明确作用域、布尔值加is/has前缀、常量带单位，且需随变量演进持续重构。

变量名本身能表达逻辑，就别靠注释补救

很多注释其实是“变量名没说清，只好用文字再解释一遍”。比如 const d = new Date().getDate()，后面跟一句 // 获取当前日期，本质是 d 这个名字没承担起说明职责。换成 const todayDate = new Date().getDate()，注释自然消失。命名不是为了“让机器运行”，而是让下一个人（包括三天后的你）扫一眼就懂上下文。

用完整单词+业务语境组合命名，避免缩写猜谜

常见错误是把 userInf、tmpObj、resData 当成省事写法，结果每次读到都得停顿半秒去脑补。实际开发中，多敲几个字母的成本远低于反复查上下文的理解成本。

• userInf → 改为 userInfo 或更具体如 currentUserProfile
• tmpObj → 明确用途，如 cachedApiResponse、normalizedFormData
• resData → 拆解来源与含义，如 apiResponsePayload、paymentResultBody

关键点：命名里带动词或名词修饰（is、has、should、validated、pending）比纯名词更能传递状态，比如 isEmailVerified 比 emailStatus 更少歧义。

区分作用域，小范围可简，大范围必须全

函数内部循环里的临时计数器用 i、idx 没问题；但模块顶层、API 响应解析层、状态管理中的字段，必须用完整、无歧义的名称。否则一旦跨文件引用，data 到底是后端原始响应、还是前端处理过的视图模型，根本分不清。

• 局部作用域（函数内）：item、acc、sum 可接受
• 模块/类/接口级：orderLineItems、shippingAddressValidationErrors、userPreferenceSettings
• 避免靠注释“打补丁”：比如 const v = getVal(); // 用户余额（单位：分），不如直接写 const userBalanceInCents

常量和布尔值命名要自带判断语义

布尔变量名如果不能一眼看出真值含义，就等于埋雷。比如 const loading = true，没人知道这是“正在加载”还是“加载完成”。同理，常量若只写 MAX_RETRY，不说明是次数、时间还是字节数，后续使用时就得翻文档。

• 布尔变量强制加 is/has/can/should 前缀：isFormValid、hasUnsavedChanges、shouldShowTutorial
• 常量带上单位或约束类型：MAX_RETRY_ATTEMPTS、DEFAULT_TIMEOUT_MS、MIN_PASSWORD_LENGTH
• 别用 FLAG_XXX 这类泛化前缀，它不提供任何业务信息

最常被忽略的一点：命名不是一次性的活——当一个变量从局部提升为模块级、或从简单值变成对象结构时，必须同步重审名字。比如原先是 userName，后来扩展成包含昵称、正式名、显示名的对象，还叫 userName 就会误导所有人。