Java编译器为内部类生成.class文件名的规则是「外层类名+$+内部类名」，如Outer$Inner.class；匿名类为Outer$1.class，局部类为Outer$1Helper.class，$是JVM认可的合法分隔符且刻在字节码中。
Java 编译器怎么给内部类生成 .class 文件名
Java 编译器对内部类的命名不是随意的，而是严格按「外层类名 + $ + 内部类名」拼接，再加 .class 后缀。比如 Outer 类里定义了 static class Inner，编译后就是 Outer$Inner.class。
这个 $ 是 Java 语言规范明确保留的分隔符，JVM 认它为合法标识符的一部分（但源码里不能直接用 $ 开头写类名），所以编译器放心用它做命名分隔。
-
$不是约定俗成，是javac的硬编码逻辑，你改不了 - 匿名内部类会变成
Outer$1.class、Outer$2.class，数字按出现顺序递增 - 局部内部类（在方法里定义的）也走同样规则，比如叫
Helper，就生成Outer$1Helper.class - 如果内部类名本身含
$（极少但合法），编译器会照搬，不会转义或替换
为什么不能直接用 Inner.class 或其他名字
因为 JVM 加载类时靠的是二进制名称（binary name），而 Java 规范规定：内部类的二进制名必须体现其嵌套关系，格式为 Outer$Inner。如果编译器生成 Inner.class，JVM 就无法把该文件和 Outer 关联起来——它不知道这个 Inner 是哪个外层类的成员，也无法校验访问权限（比如 private 内部类只能被外层访问）。
- 类加载器通过
ClassLoader.loadClass("Outer$Inner")才能正确定位并加载 - 反射调用
Class.forName("Outer.Inner")时，JVM 会自动把.转成$去找文件 - 如果你手动重命名
Outer$Inner.class为Inner.class，java命令直接报ClassNotFoundException
$ 在字节码和反射中到底起什么作用
$ 不只是文件名里的装饰，它刻在字节码的 Constant Pool 里，影响类的全限定名、签名、甚至调试信息。比如 javap -v Outer$Inner 会显示 InnerClass 属性明确记录：inner_class_info: #2 // Outer 和 outer_class_info: #3 // Outer$Inner。
- 反编译工具（如
jad、CFR）依赖这个结构还原嵌套关系 - IDE 调试时断点打在内部类里，底层靠的就是
Outer$Inner这个名字匹配行号表 - ProGuard / R8 混淆时，如果没配置保留内部类结构，可能把
$替换掉，导致运行时报NoClassDefFoundError
常见混淆或打包场景下容易出问题的地方
构建工具（Maven、Gradle）或打包工具（jar、shadowJar）一般能正确处理 $ 命名，但一旦涉及手动操作或非标准流程，就容易翻车。
- 用
zip命令手动删.class文件时，别漏掉*$*.class——否则残留的Outer$Inner.class可能引发VerifyError - 某些老旧的 IDE 插件或代码扫描工具，把
$当作非法字符跳过，导致内部类没被检查到 - Docker 镜像里用
alpine+openjdk时，如果基础镜像 JDK 版本太低（如8u111），可能不识别高版本生成的$嵌套结构，抛IncompatibleClassChangeError - Android 上使用
desugar时，如果Inner用了 Java 8+ 特性，$名称会被保留，但 lambda 生成的$类可能和内部类冲突，需要看desugar_jdk_libs版本
真正麻烦的从来不是命名规则本身，而是有人以为 $ 是临时符号可以忽略，结果在类路径、热替换、模块化或跨版本迁移时，卡在找不到那个带美元的文件上。
