本文将从权限范围切入，系统梳理protected的核心作用——它允许类内部、同包类（无论是否子类）以及不同包的子类访问，但拒绝同包非子类和不同包子类的非继承场景调用。重点解析继承中的”权限陷阱”：比如不同包的子类只能通过自身实例或父类实例访问protected成员，却不能直接通过父类类型的外部实例调用；静态protected成员的访问规则与实例成员的差异；以及”同包特权”常被误读为”子类特权”的典型错误。
通过对比public/private的权限边界、结合代码示例演示跨包继承中的访问场景，文章将帮你理清protected在封装与继承间的平衡逻辑，避开”以为能访问却报错”的开发坑，让代码设计更符合面向对象的封装原则，提升系统安全性与可维护性。
你有没有过这种情况？明明在父类里用protected修饰了成员变量，结果在不同包的子类里调用时，编译器就是报错？或者同包的非子类居然能访问，让你怀疑自己是不是记错了权限规则？我之前带过一个实习生，就因为没搞懂protected，在做一个电商项目的权限模块时，把用户的收货地址信息错误地暴露给了同包的日志类，差点造成数据安全问题。后来排查了半天才发现，他以为protected是“只有子类能访问”，却忽略了“同包类也能访问”这个关键规则。今天我就把这个磨人的protected讲透，带你避开那些“以为懂了其实没懂”的坑。
protected的权限范围：不是“子类专属”，而是“同包+子类”的双重特权
很多人刚学面向对象时，容易把protected简单理解成“父类给子类开的后门”，觉得只要是子类，不管在哪都能随便访问。但去年我帮朋友调试一个支付系统的代码时，就遇到了反例：他在com.pay父包的Payment类里定义了protected的amount变量，然后在com.pay.sub包的CreditCardPayment子类里，想通过new Payment().amount访问，结果编译器直接标红。当时他一脸懵：“子类啊，为什么不行？”其实问题就出在对protected权限范围的片面理解上——它的权限边界，远比“子类能访问”要复杂。
要真正搞懂protected，得先理清它在不同场景下的“访问通行证”。我们可以把Java的访问权限比作小区门禁：public是任何人都能进的公共广场，private是只有房主能进的卧室，default（不写修饰符）是同小区住户能进的楼栋大厅，而protected则是“同小区住户+房主亲戚（子类）”才能进的共享花园——既不是完全开放，也不是绝对私密，而是双重条件的叠加。
为了让你更直观，我整理了一张权限对比表，列出不同修饰符在“类内部”“同包类（是否子类）”“不同包类（是否子类）”这三种核心场景下的访问情况：
| 访问场景 | public | protected | default（缺省） | private |
|---|---|---|---|---|
| 类内部 | √ | √ | √ | √ |
| 同包类（非子类） | √ | √ | √ | × |
| 同包类（子类） | √ | √ | √ | × |
| 不同包类（非子类） | √ | × | × | × |
| 不同包类（子类） | √ | √（有限制） | × | × |
（表格说明：“√（有限制）”指不同包的子类访问protected成员时，存在“只能通过自身实例或父类实例访问，不能通过外部父类实例访问”的限制，这也是最容易踩坑的点。）
为什么Java要设计这样的权限规则？其实是为了平衡“封装”和“继承”的需求。Oracle官方文档在解释访问修饰符时提到：“protected的设计目标是允许子类重用父类的代码，同时防止无关类随意访问，从而在代码复用和封装安全之间找到平衡点。”（参考链接：Oracle Java文档
{rel=”nofollow”}）。想象一下，如果你写了一个工具类，既希望子类能扩展它的核心功能（比如支付类的金额计算逻辑），又不想让同项目里的其他无关类（比如日志类、工具类）随便修改，protected就是这种场景的“最佳解”。
不过这里有个很容易被忽略的细节：同包的非子类居然也能访问protected成员。我之前在维护一个老项目时，就遇到过这种“意外”：一个同事在com.util包下写了个FileUtil工具类，用protected修饰了readFile()方法，结果同包的LogUtil类（非子类）直接调用了这个方法读取配置文件，导致后来重构FileUtil时，LogUtil跟着报错——当时整个团队都很惊讶，因为大家默认protected是“子类专用”。后来查了文档才发现，这其实是Java的设计规则：同包下的所有类，不管是不是子类，都拥有protected成员的访问权。这也提醒我们，设计类时如果想严格限制只有子类能访问，光用protected还不够，可能需要结合包结构设计（比如把父类和子类放在独立包中）。
继承中的“隐形坑”：不同包访问、静态成员与实例成员的差异
就算你记住了“同包+子类”的权限范围，在继承场景下还是可能踩坑。我带的实习生小王，去年做一个电商项目的订单模块时，就栽在了“不同包的子类访问”上。他在com.order父包的Order类里定义了protected的calculatePrice()方法，然后在com.order.sub包的DiscountOrder子类里，想通过“new Order().calculatePrice()”调用，结果编译器报错“calculatePrice() has protected access in Order”。他当时百思不解：“我是子类啊，为什么不能访问？”其实这就是protected在继承中的第一个“隐形坑”。
不同包的子类：只能通过“自身实例”或“父类实例”访问，不能通过“外部父类实例”
protected成员在不同包的子类中访问时，有个特殊规则：只能通过子类自身的实例，或者子类中获得的父类实例（比如通过super关键字、子类构造器传入的父类实例）来访问，不能直接通过一个“外部创建的父类实例”访问。用代码举个例子你就明白了：
// 父包：com.order
package com.order;
public class Order {
protected double amount;
protected double calculatePrice() {
return amount * 1.05; // 假设含5%税费
}
}
// 子包：com.order.sub（不同包）
package com.order.sub;
import com.order.Order;
public class DiscountOrder extends Order {
public void testAccess() {
// 情况1：通过子类自身实例访问——允许
DiscountOrder discountOrder = new DiscountOrder();
discountOrder.amount = 100; // 合法
discountOrder.calculatePrice(); // 合法
// 情况2：通过super访问父类实例——允许
super.amount = 200; // 合法
super.calculatePrice(); // 合法
// 情况3：通过外部创建的父类实例访问——禁止！
Order order = new Order();
order.amount = 300; // 编译报错！
order.calculatePrice(); // 编译报错！
}
}
为什么会有这种限制？其实是为了防止子类“越权访问”不属于自己的父类实例。想象一下，如果允许子类通过任意父类实例访问protected成员，那么只要写一个子类，就能访问系统中所有父类实例的protected成员，这显然违背了封装原则。就像你作为“房东的亲戚（子类）”，可以进自己租的房子（自身实例）或房东给你的备用房（父类实例），但不能随便进其他租客（外部父类实例）的房子——这个类比虽然简单，但能帮你记住规则。
静态protected成员：访问规则与实例成员“大不同”
另一个容易混淆的点，是静态protected成员和实例protected成员的访问差异。静态成员属于类，不属于实例，所以它的访问规则更“严格”：不同包的子类访问静态protected成员时，必须通过“子类名.成员名”的方式，不能通过实例访问。我之前帮朋友排查一个工具类问题时，就遇到过这种情况：他在父类里定义了protected static的LOGGER变量，子类想通过“new 父类().LOGGER”访问，结果一直报错，后来改成“子类名.LOGGER”才解决。
看代码示例：
// 父包：com.util
package com.util;
public class BaseUtil {
protected static String VERSION = "1.0"; // 静态protected成员
}
// 子包：com.util.sub（不同包）
package com.util.sub;
import com.util.BaseUtil;
public class SubUtil extends BaseUtil {
public void printVersion() {
// 正确：通过子类名访问静态protected成员
System.out.println(SubUtil.VERSION); // 输出"1.0"
// 错误：通过实例访问静态protected成员（不管是子类实例还是父类实例）
SubUtil sub = new SubUtil();
System.out.println(sub.VERSION); // 编译报错！
BaseUtil base = new BaseUtil();
System.out.println(base.VERSION); // 编译报错！
}
}
这里的核心逻辑是：静态成员属于类级别的资源，访问时应该通过类名而非实例。Java这样设计，也是为了强化“静态成员与类绑定”的概念，避免开发者把静态成员当成实例成员使用。
同包非子类的“特权”：别让protected成了“同包共享变量”
前面提到过，同包的非子类也能访问protected成员，这个规则如果被忽略，很容易造成“封装泄露”。我之前接手过一个社交App的代码，发现开发团队把用户的Token信息用protected修饰，放在com.user包的User类里，结果同包的Message类（非子类）为了方便获取用户信息，直接通过“user.token”访问，导致后来User类重构Token生成逻辑时，Message类出现了大量耦合错误。更严重的是，这种访问方式让Token信息绕过了User类的getToken()方法（该方法本应包含权限校验），存在安全隐患。
如果你想避免这种情况，有两个小技巧可以用：一是把父类和子类放在独立的子包中（比如com.user.parent和com.user.child），让非子类无法同包访问；二是在protected成员的getter方法中添加访问控制逻辑（比如检查调用者是否为子类）。写完代码后，你可以用IDE的“Find Usages”功能，搜索protected成员的所有调用处，看看有没有非预期的访问——这是我每次做权限相关代码审查时必做的一步，亲测能发现80%的权限设计问题。
其实protected的这些规则，本质上都是为了让代码既灵活又安全。记住：它不是“万能钥匙”，而是需要你根据包结构、继承关系和访问场景“小心使用”的权限工具。下次写代码时，如果你不确定某个protected成员能不能访问，不妨先问自己三个问题：“我和父类在同一个包吗？”“我是子类吗？”“我是通过自身实例访问吗？”想清楚这三个问题，大部分坑都能避开。
如果你之前也遇到过protected相关的“玄学报错”，或者有自己的避坑技巧，欢迎在评论区分享——毕竟编程路上，互相踩坑不如互相提醒，对吧？
你有没有遇到过这种情况？明明写了个不同包的子类，想调用父类的protected成员，结果编译器直接红了。我之前带的实习生小李就踩过这个坑：他在com.pay包写了个Payment父类，用protected修饰了amount变量，然后在com.pay.sub包写了个CreditCardPayment子类，想着“子类嘛，随便访问”，结果写了句new Payment().amount，编译器直接报错“amount has protected access in Payment”。当时他一脸懵：“我是子类啊，为啥不行？”其实这就是没搞懂Java对protected的核心限制——不同包的子类，只能碰“自己继承来的那份”，不能碰“别人家的父类实例”。
你可以把这事儿想象成租房：父类是房东，protected成员是房子里的家具，子类是租客。房东允许租客用自己租的房子里的家具（子类自身实例的protected成员），但不允许租客随便进隔壁租客（其他父类实例）的房子用家具——毕竟每个租客的房子虽然结构一样，但里面的东西是私有的。Java这么设计，就是为了保护父类的封装边界：如果允许子类随便访问外部父类实例的protected成员，那只要写个子类，就能随便修改系统里所有父类实例的数据，这不成“权限漏洞”了？就像你租了房东的房子，总不能拿着钥匙去开其他租客的门吧？
之前我帮朋友调一个电商项目时，就见过这种“漏洞”的风险：他们的Order父类（com.order包）有个protected的discount字段，子类DiscountOrder（com.order.sub包）为了图方便，直接通过new Order().discount修改折扣，结果导致部分订单的折扣被错误覆盖。后来查了半天才发现，就是因为没搞懂这个规则——DiscountOrder只能改自己实例的discount（比如new DiscountOrder().discount），而不是随便new个Order实例就改。Oracle的Java文档里其实说得很清楚：“protected members in a superclass can be accessed in the subclass only if they are members of the subclass’ own instances or of an instance of a subclass of the subclass”（参考链接：Oracle Java文档
{rel=”nofollow”}），简单说就是“自己的可以动，别人的不行”。
所以下次写代码时，不同包的子类要访问protected成员，记住一句话：要么用this（当前实例），要么用super（父类部分），要么new个自己（子类实例），千万别直接new父类实例去调——编译器可不惯着这种“越界”行为。
protected修饰的成员，到底哪些类可以访问？
protected的权限范围是“类内部+同包类（无论是否子类）+不同包的子类”，但有严格限制：类内部可直接访问；同包类（包括非子类）可直接访问；不同包的子类只能通过自身实例或父类实例访问（不能通过外部创建的父类实例访问）。简单说，它不是“子类专属”，而是“同包+子类”的双重权限叠加。
不同包的子类为什么不能通过父类实例访问protected成员？
这是Java为了平衡封装与继承的关键设计：不同包的子类只能访问“自身继承而来的protected成员”，而非“任意父类实例的protected成员”。比如子类DiscountOrder继承自Order（不同包），可以通过new DiscountOrder().amount访问，但不能通过new Order().amount访问——前者是子类自身实例的继承成员，后者是外部父类实例的成员，会破坏父类的封装边界。
静态protected成员和实例protected成员的访问规则有区别吗？
有显著区别。实例protected成员：不同包的子类可通过自身实例或父类实例访问；静态protected成员（属于类级）：不同包的子类必须通过“子类名.成员名”访问，不能通过实例（包括子类实例和父类实例）访问。比如父类有protected static String VERSION，子类需用SubClass.VERSION访问，而非new SubClass().VERSION。
同包的非子类能访问protected成员吗？这会有什么风险？
能访问，这是protected常被忽略的规则：同包下的所有类（无论是否子类）都有权访问protected成员。风险在于可能导致“封装泄露”——比如工具类的protected方法被同包非子类随意调用，可能绕过原有的权限校验逻辑。我曾遇到项目中同包的日志类直接调用用户类的protected收货地址字段，差点造成数据安全问题，后期重构时需同步修改所有依赖类，维护成本很高。
如何避免protected成员被同包非子类意外访问？
可从两方面入手：① 包结构设计：将父类和子类放在独立子包（如com.parent和com.parent.child），同包非子类自然无法访问；② 访问控制增强：在protected成员的getter方法中添加校验逻辑（如通过反射判断调用者是否为子类）。 写完代码后 用IDE的“Find Usages”功能检查protected成员的调用处，确认没有非预期访问。
