Java类的访问控制仅支持public和包私有（默认）两种修饰符，顶级类不可用private或protected；包私有类用于模块内高内聚封装，内部类才支持private/protected修饰。
Java类的访问控制不是靠“选对修饰符”就能一劳永逸的事，关键在于明确类、成员、包三者之间的边界意图——public 类只能在同名文件中定义，而 default（包私有）类才是日常封装的主力。
类本身能用哪些访问修饰符？
Java 中类的访问控制仅限两种：不写任何修饰符（即包级私有），或用 public。不能用 private 或 protected 修饰顶级类——编译器会直接报错 modifier private not allowed here 或类似提示。
常见误操作是想把工具类设为 private 以防止外部实例化，这行不通；正确做法是用 final + 私有构造函数，例如：
final class StringUtils {
private StringUtils() {} // 阻止实例化
public static String trim(String s) { ... }
}
-
public类必须与文件名完全一致，且一个 .java 文件最多一个public类 - 包私有类（无修饰符）可在一个文件中定义多个，适合内部协作类、测试辅助类等
- 嵌套类（如
static内部类）才支持private/protected修饰
什么时候该用包私有类而不是 public？
包私有类不是“偷懒不加 public”，而是主动收缩可见性。它天然适配模块化设计中的“包内高内聚”原则：比如网络模块里 HttpConfig、RetryPolicy 这些配置类，只被本包内的 HttpClient 使用，就该设为包私有。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
这样做有几个实际好处：
- 避免 API 泄露：下游模块无法 import 这些类，也就不会误用或依赖内部实现细节
- 提升重构自由度：改
HttpConfig字段名或构造方式时，无需考虑跨包兼容性 - 减少 IDE 自动补全干扰：包外开发者看不到这些类，代码提示更干净
注意：如果包路径过深（如 com.example.service.impl.internal），说明包职责可能已混乱，此时应优先重构包结构，而非靠访问控制“打补丁”。
内部类的访问控制怎么配合外围类使用？
非静态内部类（inner class）默认拥有对外围类私有成员的访问权，但它的自身访问级别仍需显式声明。典型场景是把数据载体和行为封装在一起，又不想暴露给包外：
public class OrderService {
private static class OrderContext { // 包私有内部类
final String orderId;
final long timestamp;
OrderContext(String id) {
this.orderId = id;
this.timestamp = System.currentTimeMillis();
}
}
public OrderResult process(OrderRequest req) {
OrderContext ctx = new OrderContext(req.getId());
// ... 处理逻辑
}
}
-
private内部类只能被外围类访问，适合纯实现细节（如状态机的State枚举） -
package-private（无修饰符）内部类可用于包内多类共享上下文，但禁止跨包引用 - 若内部类需被序列化或反射调用，避免用
private，否则AccessibleObject.setAccessible(true)可能失效或触发 SecurityManager 拒绝
真正容易被忽略的是：访问控制解决不了“语义耦合”。哪怕把类设为 private，如果它承担了过多职责（比如同时处理数据转换、缓存策略、日志埋点），那只是把坏味道藏得更深了。
