变量命名应精准表达逻辑与业务语境，避免依赖注释补救；优先用完整单词、明确作用域、布尔值加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 就会误导所有人。
