Java 7 的下划线数字分隔符仅是源码级语法糖，编译后被移除，不影响运行时；不支持字符串解析（如 parseInt）、外部配置、序列化等场景，仅限字面量中间使用。
Java 7 的 _ 数字分隔符只在源码中有效
它纯粹是编译器层面的语法糖，不会影响运行时行为、字节码或数值本身。你写 1_000_000 和 1000000 编译后完全等价。
常见错误现象：有人以为它能用于字符串转数字（比如 Integer.parseInt("1_000")），结果抛出 NumberFormatException —— 这是错的，parseInt 不认识下划线。
- 只能出现在数字字面量中间，不能开头、结尾，也不能连续出现：
123_456✅，_123❌，123__456❌，123_❌ - 二进制、十六进制、八进制都支持：
0b1010_1100、0xFF_FF_00_00、0777_000 - 小数和科学计数法也支持：
1_234.567_89、1.23e_4（但e_4中的下划线不被允许，正确写法是1.23e4或12300.0）
哪些地方不能用 _ 分隔符
它不是通用格式化工具，仅限于 Java 源码中的字面量。任何运行时涉及字符串解析、序列化、配置文件读取的场景，都不认这个符号。
使用场景举例：读取 JSON 配置时字段值是 "max_connections": "1000000"，你不能写成 "1_000_000" —— Jackson/Gson 会直接报错。
立即学习“Java免费学习笔记（深入）”；
-
Integer.valueOf()、Double.parseDouble()等所有解析方法均不支持下划线 - 属性文件（
.properties）、YAML、XML 中的数值字符串不能加_ - 数据库 JDBC 查询结果、ResultSet 取出的字符串值也不支持自动识别
- 注解参数里可以写（因为是编译期常量），但反射读出来仍是纯数字
和 String.format / NumberFormat 的区别别搞混
_ 是写代码时给人看的，而 String.format("%,d", 1000000) 是运行时生成带逗号的字符串。两者目标不同，不可替代。
容易踩的坑：有人想“统一用下划线提升可读性”，结果在日志输出或 API 响应里硬塞 1_000_000 字符串，导致前端解析失败或监控系统无法提取指标。
-
_不改变类型，int还是int；String.format输出的是String - 国际化场景下，千分位分隔符可能是空格、点或逗号（如德国用
1.000.000），_完全不参与本地化 - 性能无差异 —— 编译阶段就抹掉了，不影响 class 文件大小或执行速度
Java 7+ 都支持，但要注意 IDE 和构建工具版本
只要用 JDK 7 或更高版本编译，就能用。但老版本 IDE（如 Eclipse Kepler 以前）可能报红，不是语法错，是编辑器没更新词法分析规则。
Gradle/Maven 构建时若指定 sourceCompatibility = 1.6，即使 JDK 是 17，也会编译失败 —— 因为语言级别没开。
- Maven 中确认
<source>7</source>或更高（推荐显式设为11或17） - IntelliJ 默认支持，但旧项目可能缓存了错误 SDK 配置，需检查 Project SDK 和 Language Level
- Android 开发注意：minSdkVersion ≥ 26 才支持 Java 8+ 特性，但下划线是 Java 7 特性，所以 Android 4.4+（API 19）起就可用
