大型java项目中全局常量须用public static final声明，命名全大写加下划线，按领域集中定义在专用常量类中，统一通过“类名.常量名”访问，禁用接口定义和实例引用。
在大型 Java 项目中，规范使用 static 定义全局常量，核心不是堆砌修饰符，而是让“类级别、不可变、可发现”这三点在代码中一目了然——命名、位置、访问方式必须统一，否则团队协作和长期维护会迅速失控。
常量必须用 public static final 组合声明
缺一不可：没有 static 就不是全局一份；没有 final 就无法保证不可变；没加 public 跨包调用就得绕路或暴露内部细节。
- 基本类型或字符串字面量直接初始化，最安全也最常见：
public static final int MAX_RETRY = 3;public static final String DB_URL = "jdbc:h2:mem:test"; - 复杂值（如从配置文件读取）需在静态代码块中初始化，但要确保线程安全且只执行一次：
static { DB_URL = loadFromConfig("db.url"); } - 避免在构造器、实例方法或普通代码块中赋值——那已脱离常量语义，属于运行时逻辑。
命名严格遵循全大写 + 下划线分隔
这不是风格偏好，是 Java 社区的视觉契约。IDE 和检查工具（Checkstyle、Sonar）默认识别这种格式，并对驼峰、小写开头等报错。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- ✅ 正确示例：
HTTP_TIMEOUT_MS、DEFAULT_PAGE_SIZE、IS_FEATURE_ENABLED - ❌ 错误写法：
httpTimeoutMs（像变量）、MaxRetry（驼峰）、max_retry（小写开头） - 即使常量只在本类使用，也建议用
private static final并保持同样命名——一致性比可见性更重要。
集中管理，不散落、不接口化
把常量塞进接口或到处零散定义，是大型项目中最常见的反模式。它破坏模块边界，导致编译依赖泛滥，重构成本极高。
- 按领域建专用常量类，例如：
HttpConstants、DbConstants、FeatureFlags，每个类职责单一、命名清晰。 - 禁止用接口定义常量（如
interface Constants { String KEY = "..."; }）。接口描述行为，不是数据容器；且实现该接口的类会隐式继承所有常量，造成语义污染和冲突风险。 - 避免“万能常量类”如
AllConstants——它很快变成无人敢动的黑洞。宁可多建几个小类，也不要一个大杂烩。
访问统一用“类名.常量名”，禁用对象引用
这是强制约定，不是可选项。哪怕在类内部，也应优先写 HttpConstants.TIMEOUT 而非直接写 TIMEOUT（除非已静态导入且上下文极其明确）。
- 好处：一眼看出来源，便于 IDE 跳转、全局搜索、自动化重构；杜绝同名常量覆盖或歧义。
- 禁止写法：
new HttpConstants().TIMEOUT或obj.TIMEOUT——静态成员与实例无关，这种写法传递错误信号。 - 若频繁使用某组常量，可用
import static xxx.HttpConstants.*;，但仅限于测试类或极简脚本，主业务逻辑中慎用，以防命名冲突。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
