统一常量管理需遵循五项规范：类名用“模块名+Constants”、包路径严格对应业务层级、常量全大写下划线且带功能前缀、类声明final并含私有构造、常量分组注释隔离。
项目里常量散落在各处，是后期维护最头疼的问题之一。统一设计常量类，不是为了“看起来规范”，而是让状态、配置、命令这些关键值可查、可溯、可约束。
类名与包路径要带业务语义
类名必须是 模块名 + Constants（复数），比如 UserConstants、OrderConstants，不能叫 UserConstant 或 UserConst。单数形式会误导团队以为它只存一个值。
包路径要严格对应模块层级，例如用户模块的常量放在 com.example.user.constant，公共常量统一归到 com.example.common.constant。禁止塞进 util 或 config 这类泛化包里——那等于放弃分类管理。
常量命名必须全大写+下划线，且带功能前缀
所有常量名一律大写，单词间用下划线分隔，如 CACHE_USER_TOKEN、COMMAND_SEARCH_ALL。小写或驼峰命名（如 cacheUserToken）直接视为违规。
前缀不是可选项，而是语义锚点：
-
CACHE_：用于缓存键、缓存过期时间等 -
COMMAND_：用于 MyBatis 的 SQL 命令标识、查询场景标记 -
STATUS_或直接按业务含义命名（如SUPER_ACCOUNT_TYPE）：用于状态码、类型枚举值 - 避免无意义前缀（如
CONST_），它不传递业务信息，反而稀释重点
类结构必须封闭、静态、不可实例化
常量类本质是“数据容器”，不是工具类。所以：
- 类声明加
final，防止被继承 - 必须有私有无参构造方法，方法体留空，仅注释“禁止实例化”
- 每个常量都用
public static final修饰，三者缺一不可——漏掉static就无法直接通过类名调用；漏掉final就可能被意外修改
不写构造方法？Java 默认生成 public 构造，别人 new 出来就破坏了设计本意。
按功能分组，用标准注释隔开
把几十个常量堆在一起，没人愿意读。必须按用途划分区块，并用统一格式的分隔注释隔离：
// ========== 业务状态常量 ==========// ========== 缓存相关常量 ==========// ========== 查询命令常量 ==========
每组之间空一行，同组内常量按字母或逻辑顺序排列。这样新成员加一个 CACHE_ORDER_DETAIL，一眼就知道该放哪一块，不会随手插在中间。
不复杂但容易忽略。
