JavaScript变量命名最佳方式及var/const/let声明选择指南

核心选择优先级非常明确：日常业务开发优先默认用const，仅当变量需要重新赋值时用let，非特殊兼容场景彻底弃用var，具体判断标准如下：

• 优先使用const的场景
  只要变量初始化后不会被重新绑定新值，不管是基础类型还是引用类型，直接选const。
  很多人误以为const只能定义不可变常量，实际上它限制的是变量和内存地址的绑定关系，不是值本身不可修改：定义对象、数组这类引用类型时，修改对象属性、给数组增删元素都不算重新绑定，完全可以用const。

// 合法的const用法
const user = { name: "Li", age: 25 };
user.age = 26; // 不触发报错，修改内部属性不受限制
const tagList = ["js", "css"];
tagList.push("html"); // 不触发报错，修改数组成员不受限制

用const的实际收益很直接：一是读代码的人一眼就能确认这个变量不会被重新赋值，降低心智负担；二是避免手误重复赋值导致的隐蔽bug，同时JS引擎对const的编译优化空间更大，运行性能也略好。

• 选择let的场景
  仅当你明确需要变量在后续逻辑中被重新赋值时，才用let。比如分页场景的当前页码、循环计数器、需要根据多分支条件动态赋值的变量：

// 合法的let用法
let currentPage = 1;
// 翻页逻辑中会对currentPage重新赋值
for (let i = 0; i < list.length; i++) {
  // let声明的i是块级作用域，不会泄露到循环外部
}

let是块级作用域，不存在var的变量提升、全局污染问题，是ES6之后标准的可变变量声明方式。

• 彻底弃用var的原因
  var是ES6之前的旧时代语法，没有块级作用域，仅支持函数作用域/全局作用域，存在变量提升、重复声明不报错、全局声明自动挂载到全局对象上等设计缺陷，非常容易写出难以排查的bug，最经典的坑就是循环定时器问题：

// var的典型问题
for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100); 
  // 预期打印0、1、2，实际会打印3次3
}

目前主流的Lint规则、团队规范都会默认禁用var，除非你需要兼容IE8及更早的古董浏览器，否则完全没有使用var的必要。

以下都是行业经过十几年踩坑沉淀下来的通用规范，照着做能少写很多无意义的bug：

• 先守住基础语法红线
  • 变量名只能包含字母、数字、下划线、$符号，不能以数字开头，不能和JS保留字（比如class、function、await等）重名
  • JS变量严格区分大小写，appId和appid是两个完全独立的变量，不要靠大小写区分相似变量，非常容易写错
• 语义优先，拒绝无意义命名
  • 变量名要直接描述存储的内容，布尔类型变量优先加is/has/can这类前缀，比如isVip、hasEditPermission、canExport，看名字就能知道变量类型和用途
  • 除了循环计数器i/j/k这类全行业约定俗成的短名，不要用a、b、temp、data1这类无意义名字，哪怕名字长一点，也比后续读代码时猜半天变量用途强。比如存储用户列表就叫userList，别缩写成ul——后者很容易和HTML的ul标签混淆。
• 统一命名风格，不要混杂
  • 普通变量、函数统一用小驼峰（camelCase），比如getUserInfo、currentActiveTab，这是JS社区的默认约定
  • 构造函数、ES6 Class类名用大驼峰（PascalCase），比如User、RequestClient、CustomForm
  • 写死的、全场景不会修改的编译期常量用全大写+下划线分隔的格式，比如const MAX_UPLOAD_SIZE = 10 * 1024 * 1024、const DEFAULT_AVATAR = '/static/default-avatar.png'
  • 不要用下划线开头标记私有变量，现在JS已经有标准的私有属性语法#，下划线前缀是早期JS没有私有语法时的妥协方案，新代码直接用标准语法即可
• 避开常见的命名坑
  • 不要用name、length、top这类DOM/全局对象自带的属性名做全局变量名，很容易出现值被默认覆盖的诡异问题
  • 不要拼音、英文混写，更不要直接用全拼音命名（行业通用的专有名词拼音除外，比如人名、城市名），比如别把收货地址变量命名为shouhuoAddress，直接用deliveryAddress更通用
  • 布尔值不要用否定式命名，比如别写isNotLogin，后续判断时写if (!isNotLogin)要绕两层逻辑，非常容易写反判断条件，直接用肯定式的isLogin即可

内容的提问来源于stack exchange，提问作者GoodY Programmer Boy