变量声明需遵循作用域最小化、可变性最小化、意图明确化原则：配置用const大写下划线，页面状态用let/const按需声明，临时值限块级作用域，引用类型优先const+方法修改。
变量声明不是写完就完的事，而是要从项目结构、协作规范和长期维护角度提前想清楚。核心原则是：作用域越小越好，可变性越少越好，声明意图越明确越好。
按用途分层规划变量类型
项目中变量不是随便起名、随手声明的，应按数据特性归类：
-
配置常量（API 地址、超时时间、状态码映射）——统一用
const声明在config/或constants/目录下，全部大写下划线命名，如const API_TIMEOUT = 5000; -
页面级状态（表单输入值、开关状态、当前页码）——在组件顶层或模块作用域用
let，避免函数内重复定义；若只读可改用const+ 解构赋值 -
临时计算值（循环中的累加器、条件分支里的中间结果）——严格限制在最小块级作用域内，用
let，不提升、不复用 -
引用类型容器（
userList,cartItems）——默认用const声明，靠方法（.push(),.splice()）修改内容，而非重新赋值
按作用域控制声明位置
避免“到处都能改”的混乱局面，关键看变量谁需要访问、谁负责更新：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 整个模块共用的状态（如共享的 loading 标志）——在模块顶层用
let或const声明，不暴露到全局 - 仅某几个函数协作的数据（如缓存计算结果）——用闭包包裹，或封装为模块私有变量，不挂
window - 跨组件通信场景——不用全局变量，改用事件总线、Context API 或状态管理库（如 Zustand、Pinia），让数据流向可追踪
- 绝对禁止在函数内部漏掉
let/const直接赋值（如userName = "Tom"），这会意外创建全局属性，尤其在严格模式下直接报错
按团队规范统一书写习惯
多人协作时，变量声明方式直接影响代码可读性和排查效率：
立即学习“Java免费学习笔记（深入）”；
- 一行只声明一个变量，即使类型相同也不逗号连写（
let name = "A"; let age = 25;），便于 Git 差异对比和注释说明 - 声明与首次赋值尽量靠近，避免“先声明后几十行才赋值”的情况；若必须延迟赋值，加注释说明原因
- 函数参数默认视为
const（不可重新赋值），如需修改建议解构或新建变量，防止副作用扩散 - 所有变量名使用语义化英文，避免
data1、temp这类模糊名称；布尔值推荐加is/has/can前缀（如isLoading,hasPermission）
避开常见陷阱的硬性约束
这些不是建议，而是上线前静态检查（ESLint）应强制拦截的行为：
- 禁用
var—— 它的函数作用域和变量提升极易引发时序错误，现代项目已无合理使用场景 - 禁止隐式全局 —— 所有变量必须显式用
let/const声明，ESLint 配置no-implicit-globals和no-unused-vars - 禁止在条件块外访问块级变量 —— 如
if内用let声明的变量，不得在if外读取，否则运行时报ReferenceError - 禁止用
const声明后又试图重新赋值（const x = 1; x = 2;），编译阶段即报错，这是保护逻辑稳定性的第一道防线
