Java评分逻辑应优先用if-else配合左闭右开边界（如score>=90）处理分数等级，统一阈值为常量，校验非法输入（NaN、无穷、越界），避免浮点误差与硬编码。
用 if-else 分支判断分数等级
Java 里最直接的评分逻辑就是根据数值范围输出对应等级，比如 90–100 是 A，80–89 是 B。关键不是“怎么写分支”，而是**边界值处理是否一致**——score >= 90 和 score > 89 表面等价，但遇到浮点输入或未来扩展小数评分时行为可能不同。
推荐统一用“左闭右开”习惯（如 score >= 90 && score ），避免漏掉满分或重复覆盖：
if (score >= 90) {
grade = "A";
} else if (score >= 80) {
grade = "B";
} else if (score >= 70) {
grade = "C";
} else if (score >= 60) {
grade = "D";
} else {
grade = "F";
}
- 别用
==判断分数段（比如score == 95），这不适用于区间判定 - 确保
score是double或int，避免传入null导致NullPointerException - 如果分数可能为负或超 100，提前加校验，否则 “F” 分支会掩盖数据异常
用 switch + Java 14+ 模式匹配简化多档判断
Java 14 起支持 switch 表达式配合模式匹配，但注意：它**不能直接对区间做 case**，必须先将分数转为离散等级码（比如用 (int) score / 10 得到 0–10 的整数）。
适合分数严格为整数、且分档规则是 10 分一档的场景：
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
int band = Math.max(0, Math.min(10, (int) score / 10)); // 限定在 0–10
String grade = switch (band) {
case 10 -> "A"; // 100–109（实际只会到100）
case 9 -> "A"; // 90–99
case 8 -> "B"; // 80–89
case 7 -> "C"; // 70–79
case 6 -> "D"; // 60–69
default -> "F"; // 0–59
};
- 必须用
Math.max/min防止band越界，否则switch会抛IllegalArgumentException - 该写法牺牲了可读性换简洁性，若分档不规则（如 85 才算 B），不如退回 if-else
- Java 13 及更早版本不支持 switch 表达式，编译会报错
error: switch expressions are not supported
封装成方法并处理非法输入
真实项目中，评分逻辑不会裸写在 main 里，而应封装为独立方法，重点在于**提前拦截坏数据**，而不是让调用方承担校验责任。
典型错误是忽略 Double.NaN、无穷大或非数字字符串转换失败：
public static String getGrade(double score) {
if (Double.isNaN(score) || Double.isInfinite(score)) {
throw new IllegalArgumentException("Score must be a valid finite number");
}
if (score < 0 || score > 100) {
throw new IllegalArgumentException("Score must be between 0 and 100");
}
// ... 后续 if-else 判断
}
- 不要依赖调用方“传进来就是合法的”，尤其当分数来自用户输入或 CSV 解析时
- 异常类型选
IllegalArgumentException比RuntimeException更明确 - 如果系统要求容忍异常值，可返回
"N/A"或null，但需在 Javadoc 明确说明
避免硬编码和魔数，提升可维护性
把 90、80 这类数字直接写死在 if 条件里，后续调整分级标准（比如 B 线从 80 改成 82）就得改多处，极易遗漏。
用静态常量或配置化方式管理阈值：
private static final double A_MIN = 90.0; private static final double B_MIN = 80.0; private static final double C_MIN = 70.0; private static final double D_MIN = 60.0; if (score >= A_MIN) grade = "A"; else if (score >= B_MIN) grade = "B"; // ...
- 常量名要体现业务含义（
A_MIN比THRESHOLD_1好懂） - 如果分级规则频繁变动，考虑从外部配置文件或数据库加载，而非改代码
- 注意浮点比较误差：用
score >= 80.0安全，但避免score == 80.0判定临界点
边界条件永远比主流程更易出错，比如刚好 60.0 分该算 D 还是 F、用户输了个空字符串转成 0.0 是否合理——这些细节不写进测试用例，上线后就会变成凌晨三点的报警。
