在 React、Umi 等前端项目中，常量采用全大写命名（如TIME_RANGE_OPTIONS）是社区约定俗成的规范，核心原因可以从三个层面理解：
- 语言层面：区分 "不可变" 的语义信号
JavaScript 中 const 关键字声明的变量虽然并非绝对 "常量"（对象 / 数组的内部属性可修改），但全大写命名本质是一种语义约定—— 向开发者传递 "此值不应该被重新赋值" 的信号。
比如此次导入的 RANGE_PRESETS，通常是固定的时间范围配置（如 [{label: '今日', value: 'today'}] ），大写命名能直观区分于普通变量（如 let currentRange = 'week' ），减少误修改的风险。
- 框架实践：与模块化思想的契合
React/Umi 等框架强调模块化拆分，常量常被集中管理在 constants.js 这类文件中（如你的示例）。全大写 + 下划线分隔的命名风格：
- 符合蛇形命名法的衍生规则（针对常量的变种），与变量的小驼峰（如 userInfo ）、组件的大驼峰（如 TimePicker ）形成明确区分
- 便于团队快速识别 "配置型常量"（如 CHART_ADAPTERS 这类图表适配器映射关系），提升代码扫描效率
- 历史传承：前端与后端规范的共识
这种命名方式源自 C 语言等传统编程语言的常量命名习惯（如 #define MAX_SIZE 100 ），前端在发展中借鉴了这一约定。尤其在多人协作的中大型项目（Umi 常用于企业级应用）中，统一的命名规范能降低沟通成本 —— 即使不看注释，也能通过命名判断变量性质。
例外情况：如果常量是 "模块内私有" 且语义简单（如 const limit = 10 ），有时会用小写，但导出供外部使用的公共常量，全大写仍是更稳妥的选择。
