可借助spotbugs自定义detector或javaparser脚本，识别方法参数、字段赋值、switch case中语义匹配枚举的硬编码字面量，并结合上下文命名、类型及项目枚举定义进行精准检测。
直接用自动化脚本扫描 Java 工程中“该用枚举却写死数值”的问题，核心是识别两类关键模式：一是字面量（如 1、"PENDING"）出现在本该引用枚举常量的位置；二是这些字面量语义上与已有枚举的值高度重合。这不是单纯找数字或字符串，而是结合上下文语义+类型边界+项目约定的轻量级静态分析。
明确扫描目标：哪些“硬编码”算坏味道？
不是所有字面量都要改，重点抓三类高风险场景：
-
方法参数位置出现基础类型字面量，而该方法签名在项目中存在对应枚举类型的重载，或 Javadoc/命名暗示应传枚举（如方法叫
setStatus(int status)，但项目已有OrderStatus枚举且含PENDING=1） -
字段赋值或条件判断中使用字面量，且左侧变量名/常量名与某枚举类名或其常量名强相关（如
int state = 2;+ 上方注释写 “// 2: PROCESSING” 或变量名是orderState） -
switch 表达式中 case 使用整数字面量或字符串字面量，而 switch 变量类型是 int/String，但项目中存在语义匹配的枚举（如
switch (type) { case 0: ... case 1: ... }，同时存在MessageType { TEXT(0), IMAGE(1) }）
用 SpotBugs + 自定义 detector 快速落地（推荐）
SpotBugs 支持编写自定义 detector，比纯正则更可靠。只需两步：
-
提取项目中所有枚举定义：用 JavaParser 或简单 AST 扫描，收集每个枚举类名、常量名、ordinal 值、assigned 值（如
OPEN(100)）、toString() 字面量（如有重写） -
编写 detector 匹配“可疑字面量”上下文：例如当发现
ICONST_1指令（编译后整数 1）被传入名为setRole的方法，且当前类存在Role枚举含ADMIN(1)，就报 warning；字符串同理，用 Levenshtein 距离 ≤2 判定名称相似性（如"admin"vsRole.ADMIN.name()）
无需改构建流程，加到 spotbugs-exclude.xml 后即可集成进 Maven/Gradle。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
轻量替代方案：AST + 正则组合扫描（零依赖）
若不想引入 SpotBugs，可用 JavaParser 写个 CLI 脚本：
- 遍历所有
.java文件，解析为 CompilationUnit - 先收集所有枚举：遍历
EnumDeclaration，存{枚举类名 → Map}，值包括 ordinal、构造参数、name() 字符串 - 再扫描表达式：
IntegerLiteralExpr/StringLiteralExpr出现在以下任一上下文即标记：- 父节点是
MethodCallExpr且方法名含set|with|of|from等动词 + 参数名含type|state|status|role|level - 父节点是
AssignExpr且左侧变量名以xxxType/xxxState结尾 - 父节点是
SwitchEntry且所在 switch 变量类型为 int/String，且变量名在白名单内（如status,code）
- 父节点是
输出格式示例：OrderService.java:42: use 'OrderStatus.PENDING' instead of literal 1，开发可直接跳转修复。
配套建议：建立“枚举使用规范”并嵌入 CI
扫描只是起点，防止复发更重要：
- 在团队 Confluence 明确列出“禁止硬编码”的字段名关键词（如
*Status,*Type,*Level），并附对应枚举类路径 - 用 Checkstyle 自定义
IllegalInstantiation规则，禁止 new 枚举外的同类名类（防误建Status类） - CI 阶段运行扫描脚本，失败时输出 HTML 报告链接，并阻断 PR（阈值设为 0 个新问题）
不复杂但容易忽略：第一次全量扫描会发现大量历史坏味道，建议按模块分批修复，优先处理核心领域模型和对外 API 层。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
