jls第6.4节关于局部类重名的“unless”条款并非冗余，而是对第8.1节嵌套类命名限制的有意放宽，允许在特定嵌套结构中合法地重用局部类名，实现受控的名称遮蔽。
jls第6.4节关于局部类重名的“unless”条款并非冗余，而是对第8.1节嵌套类命名限制的有意放宽，允许在特定嵌套结构中合法地重用局部类名，实现受控的名称遮蔽。
Java语言规范（JLS）在命名约束上存在看似矛盾、实则精巧分层的设计。关键在于区分两类作用域场景：方法体内的局部作用域（含局部类、局部接口）与类/接口声明的静态嵌套结构（如成员内部类、静态嵌套类）。
JLS §8.1 规定：一个类不得与其任意直接或间接封闭类/接口具有相同的简单名（simple name）。这是严格的静态嵌套命名约束，适用于
class Outer { class Inner { class Inner {} } }这类结构——编译器会报错，因为内层Inner与外层Inner构成同名封闭关系。JLS §6.4 则聚焦于局部类（local class）的动态作用域：它禁止在同一作用域内重复声明同名局部类（例如连续两次
class C {}），但通过unless子句明确允许一种例外——当新声明的局部类位于C自身作用域内某个类或接口声明的内部时，该重名是合法的。
这正是“受控遮蔽（controlled shadowing）”机制：局部类的作用域可被更深层的嵌套类所“隔离”，从而打破 §8.1 的全局封闭链判断。例如以下代码完全合法（JDK 17+ 编译通过）：
立即学习“Java免费学习笔记（深入）”；
public class Test {
public void foo() {
class C { } // 局部类 C，作用域为 foo() 方法体
class Wrapper { // 声明在 C 的作用域内（即 foo() 内）
public void use() {
class C { } // ✅ 合法：此 C 声明在 Wrapper 类内，而 Wrapper 本身在 C 的作用域中
// 它不被视为 C 的“enclosing class”，因此 §8.1 不触发
}
}
}
}⚠️ 注意事项：
- 遮蔽仅对局部类/接口有效；§8.1 对成员内部类（
class Outer { class Inner {} }）仍严格生效； -
unless条款不适用于匿名类或 Lambda 表达式内部的局部类声明（因其无显式名字，不构成重名问题）； - 此设计支持模式化编程，例如在测试辅助类中复用领域模型类名，而不污染外层作用域。
综上，§6.4 的 unless 并非冗余补丁，而是 JLS 在保持类型安全前提下，赋予开发者更灵活的作用域建模能力的关键语义开关——它让局部作用域与嵌套声明之间形成可穿透的边界，而非不可逾越的屏障。
