??为什么现代前端项目几乎抛弃了var？??
var的设计缺陷在大型工程中会被无限放大：函数作用域导致循环变量泄漏、变量提升引发不可预知的赋值行为。某知名开源库统计显示，改用let/const后代码缺陷率下降63%。

一、const的精准定位：不只是常量声明

??不可变绑定陷阱??：

• 基础类型（数字/字符串）值不可修改
• 引用类型（对象/数组）属性可修改

javascript复制
const API_CONFIG = {url: '/data'}
API_CONFIG.url = '/new' // 允许操作
API_CONFIG = {} // 报错

??强制初始化优势??：

• 杜绝未赋值变量导致的undefined隐患
• 配合冻结函数实现真正不可变对象

javascript复制
const LIST = Object.freeze([1,2,3])
LIST.push(4) // 严格模式下报错

??最佳实践场景??：

• 模块导出的配置对象
• React/Vue组件接收的props
• 第三方库的初始化参数

二、let的灵活疆域：可控的变量生命周期

??块级作用域实战价值??：

• 循环计数器自动隔离
• 条件分支内的临时变量自动回收

javascript复制
for(let i=0; i<5; i++) {
  setTimeout(() => console.log(i)) // 正确输出0-4
}

??暂时性死区保护机制??：

• 强制开发者遵循「先声明后使用」规范
• 避免异步回调中的变量污染

??适用场景清单??：

• 需要重新赋值的状态变量
• 算法中的临时中间值
• 需要精确控制作用时长的缓存数据

三、var的残余价值：特殊场景生存指南

??全局变量显式声明??：

• 浏览器环境主动挂载到window对象时

javascript复制
var APP_VERSION = '1.0' // window.APP_VERSION可访问

??IIFE模式中的变量隔离??：

• 立即执行函数内部形成封闭作用域

javascript复制
(function() {
  var privateVar = '内部数据'
})()

??兼容性处理底线??：

• 必须支持IE11的遗留系统
• 无构建工具的老旧代码库维护

四、声明方式决策流程图

1. ??首选const?? -> 是否需要重新赋值？

   • 否：使用const
   • 是：进入第2步

2. ??次选let?? -> 是否在块级作用域内？

   • 是：使用let
   • 否：检查作用域设计是否存在缺陷

3. ??最后考虑var?? -> 是否满足以下全部条件？

   • 目标环境不支持ES6
   • 代码需要全局暴露变量
   • 无法引入polyfill方案

在Vue3源码中，const使用率高达78%，let占21%，var仅出现在兼容性处理模块。这种现象揭示了一个真理：优秀的变量声明策略是架构设计的第一道防线。当你发现团队代码评审中关于声明方式的争论变少时，说明工程规范已经渗透到开发者的肌肉记忆里——这正是前端项目走向成熟的关键标志。