JavaScript中使用let声明常量的利弊、规范及劣势分析

在JavaScript里，const本来就是专门用来声明不会被重新赋值的标识符，let则是给需要后续修改的变量用的。但有些开发者会用let来声明实际不会改动的“常量”，下面聊聊这种做法的利弊，以及对应的最佳实践：

用let声明常量的唯一“优点” #

• 短代码临时修改方便：比如写快速测试片段或者原型代码时，要是后续突然需要把这个标识符改成可赋值的变量，不用把let改成const，直接加赋值语句就行，省了一次替换操作。但这完全是场景极有限的“偷懒”行为。

用let声明常量的核心劣势 #

• 语义完全错位：let的字面意思就是“允许修改”，用它声明不变的值，会让看代码的人误以为这个值后面会变，平白增加理解成本——多人协作时这种误解很容易引发bug。
• 丢失语法防护：const会在你尝试重新赋值时直接抛出错误，相当于给这个值加了一层“防误改”的保险。用let的话，万一手滑写了重新赋值的代码（比如变量名写错、逻辑失误），JS不会有任何提示，只会默默覆盖值，排查这种bug要花额外的时间。
• 违反通用规范：不管是Airbnb还是Google的JS代码规范，都明确要求用const声明不会被重新赋值的标识符。混用let声明常量会破坏团队代码的一致性，后续维护起来更麻烦。
• 模糊变量边界：长期来看，代码里的const和let应该是清晰的分界：const是“只读”，let是“可写”。混用之后，开发者得逐个确认每个标识符的实际用途，降低了代码的可读性和维护效率。

是否应该始终用const声明常量？ #

必须是肯定的，除非你明确知道这个标识符后续需要被重新赋值。

const的设计就是为了匹配“常量”的需求，它既能清晰传达代码意图，又能提供语法层面的错误防护，不管是小项目还是大型工程，这些收益都远大于短代码里那点微不足道的便捷性。

那些在短代码里用let的场景，本质上是为了省一次字符替换的功夫，牺牲了代码的可读性和安全性，完全得不偿失——毕竟代码的生命周期里，被阅读的时间远多于被修改的时间。

内容的提问来源于stack exchange，提问作者Jay-flow