常量应使用全大写加下划线命名（如MAX_RETRY_COUNT），以直观表明其不可变性，与小驼峰变量形成视觉和语义区分，降低认知负担、避免误修改，并符合主流工具链与团队协作规范。
常量推荐用全大写加下划线，核心是为了让代码意图一目了然——谁看到 MAX_RETRY_COUNT 或 API_TIMEOUT_MS，立刻明白这是个固定值，不该被修改，也不该意外覆盖。
一眼识别不可变性
大小写+下划线组合在视觉上非常醒目，和小驼峰变量（如 retryCount、timeoutMs）形成强烈对比。这种差异不是为了好看，而是降低认知负担：读代码时无需查定义、不用翻上下文，就能确认“这个值不会变”。
- 看到 DEFAULT_THEME → 知道是配置项，不打算改
- 看到 isDarkMode → 知道是运行时可变的状态
- 混用命名（比如把常量写成 defaultTheme）会让团队成员反复确认它是否真不可变
符合语言生态与工具链习惯
这不是 JavaScript 强制语法，但已是事实标准。主流编辑器（VS Code、WebStorm）、ESLint 规则（如 camelcase 和 uppercase 配合）、TypeScript 类型检查都默认支持并提示该约定。JDK、Python 的 CONSTANT_NAME、甚至 HTTP 状态码（HTTP_STATUS_OK）都沿用同一逻辑。
- ESLint 默认警告：若声明为 const 却用了小驼峰，会提示“常量应大写”
- 团队协作中，新成员第一天就能靠命名快速理解哪些值是系统边界值、哪些是业务中间态
避免语义混淆和误操作
小驼峰变量天然暗示“可能变化”，比如 maxRetries 看起来像一个可配置的参数；而 MAX_RETRIES 明确传递“这是硬编码上限，改它要走发布流程”。这种区分能防止低级错误：
立即学习“Java免费学习笔记（深入）”；
- 误把 maxRetries = 5 当成可动态调整，结果在循环里反复赋值
- 把 API_BASE_URL 当成普通变量，在条件分支里重赋值，导致后续请求发错地址
- 多人协作时，有人以为 userRole 是常量，结果另一个人在别处改了它的值
私有常量也建议保持风格统一
即使某个常量只在单个模块内使用（如 _INTERNAL_BUFFER_SIZE），仍推荐全大写。下划线前缀表示“内部使用”，全大写表示“不可变”，两者不冲突，反而叠加强化语义。不必为了“私有”就退回到小驼峰，那会削弱一致性。
- ✅ _MAX_BATCH_SIZE —— 清晰表达：内部使用 + 固定值
- ❌ _maxBatchSize —— 下划线暗示私有，但小驼峰又像可变变量，产生歧义
