1. 访问修饰符到底是什么从一个“失控”的类讲起先别急着背定义。我直接说一个很多初级工程师都干过的事写了一个User类字段全部用public然后业务代码里到处直接操作字段比如user.age -1、user.passwordHash whatever。等上了生产环境数据烂掉了你想约束这些赋值行为结果所有地方都在改牵一发动全身根本不敢动。这个场景我见过太多次了。说白了访问修饰符Access Modifiers不是语法层面的“装饰品”它是Java、C、C#这类面向对象语言里用来控制类成员“谁可以碰、谁不能碰”的一套边界系统。它解决的核心问题不是“防止别人恶意攻击”而是“防止你自己在三个月后手滑或者团队里其他人误用你写的类”。这篇文章适合谁看如果你是刚学完对象、继承、多态正要进入“怎么设计一个像样的类”阶段的初学者那正合适如果你写了两年业务代码但对protected和默认修饰符的区别始终模模糊糊也可以当一次系统性的复习。我会用Java为主来讲解同时把C、Python、C#这些常用语言的差异放在一起对比——毕竟现在很多人是跨语言开发的只懂一套规则很容易踩坑。1.1 先看一个没有访问修饰符的“事故现场”假设我们写一个BankAccount银行账户类用来记录余额。如果完全不设访问控制public class BankAccount { public double balance; public String ownerName; }然后业务代码里这么写BankAccount account new BankAccount(); account.balance -500; // 直接赋负值没有任何校验这段代码能编译、能运行但显然不合理。余额可以是负数但在真实的银行系统里提现、透支的规则应该是明确的业务逻辑而不是一个裸字段随便让人改。一旦这样的代码上线后续任何一次需求变更——比如“余额不能低于-1000”——你都得满项目去搜索哪个地方改了balance然后一个一个改。这就是没有访问修饰符的代价所有字段像广场一样任何人、任何时候都能进来踩一脚。访问修饰符的第一层意义就是“把字段关起来”强制要求外部代码通过方法行为来操作数据把数据校验、状态流转的规则收敛到类内部。1.2 核心价值封装、契约、安全往深一层说访问修饰符四个字背后站着的是面向对象三大特性里的“封装”。封装不是让你把代码藏起来不给人看而是明确两个东西类对外提供什么——这是公共契约别人能调用你的公开方法类内部保留什么——这是实现细节将来怎么改都不会影响调用方。公共契约一旦定了你内部怎么做都行。比如BankAccount.deposit(double amount)方法对外承诺“存钱”内部是存数据库还是写文件外部不关心。但如果外部可以直接修改balance字段那么“存钱”这个行为逻辑就被架空了契约形同虚设。从安全角度讲访问修饰符还能防止一些危险操作比如把passwordHash声明为public导致任何代码都能读甚至改密码哈希把init()这种一次性初始化方法声明为public导致运行途中别人能随时再调一次状态被重置。这些都不是“黑客攻击”问题而是“自己人误操作”问题——在实际工程中后者才是主要矛盾。1.3 先把四个级别的关系图刻在脑子里Java的访问修饰符从小到大排列访问级别同包同类同包子类同包非子类异包子类异包非子类private可以不可以不可以不可以不可以默认包私有可以可以可以不可以不可以protected可以可以可以可以不可以public可以可以可以可以可以建议把这张表抄在笔记本上这是整个访问修饰符体系最核心的一张表。后面所有疑问几乎都可以回到这张表来推导。注意关键差异点private只有定义这个成员的类自己能用。默认也叫包私有同一个包内的所有类都能用出了包就不行了。protected同包随便用异包的子类也能用。public谁都能用。这四个等级本质上是从最封闭到最开放的连续光谱。设计类的时候你的任务就是找对每个成员在这个光谱上的位置。2. 四个访问修饰符逐一拆解从最开放到最封闭2.1 public开放的公共接口public是四个修饰符里最“大方”的一个声明了它就意味着这个成员是类对外的接口面。正常情况下应该只用在下列场合对外提供服务的业务方法比如deposit()、withdraw()、getBalance()类本身要能被外部实例化所以构造函数通常也是public实现接口的方法接口方法默认就是public abstract你实现时也只能是public。但有一个高频误用把字段直接声明为public。除非是常量比如public static final int MAX_AMOUNT 50000;否则字段设计成public基本都是设计缺陷。原因我在前面说过字段没法做校验也没法在赋值时触发额外逻辑。你可能会想“我加个注释让别人别乱改不就行了”——想法太天真人的记忆是不可靠的总有一天会有人绕过你的注释。另外从演进角度看public是代价最高的修饰符。一旦你发布了这个类外界已经有人在你public方法的基础上写代码了那么这个方法后续想改签名、改行为就都受限制了。Java生态里有个著名的“破坏性变更”现象很多库升级一个小版本就因为一个public方法的行为微调导致下游大面积编译失败。你暴露出去的public越多你未来重构的自由度就越低。2.2 private类内专属谁也别想碰private是四个里最严格的只有声明它的类自己能访问子类、同包兄弟类、外部类统统不行。它为“封装”提供了最强的保障。我们通常要求字段用private除非有特殊理由所有实例字段都应该是private外部只能通过getter/setter或业务方法间接访问。辅助方法用private有些方法是纯内部实现细节比如拆分计算过程、格式化内部数据结构这些方法没理由暴露出去应该private。常量可以例外private static final你在类内部用目的是不让外部依赖这个常量值未来改值不影响外部。有一个细节经常被忽略private成员在同类内部是随便访问的包括“同类不同对象”。这句话什么意思看代码public class Person { private String name; public boolean sameName(Person other) { return this.name.equals(other.name); } }sameName方法里this.name是私有的没问题other.name同样是private字段但因为访问方是Person类自身所以照样能拿。很多初学者以为“私有字段只有当前这个对象能访问”其实是“只有当前这个类能访问”——不管对象是this还是另一个实例只要是这个类的代码就能访问private成员。这个理解偏差在实际代码里经常引发困惑。2.3 protected为继承而生的“半开放”protected的设计初衷很明确让子类能继承和使用父类的部分内部能力但对外部世界保持封闭。典型的使用场景是模板方法模式父类定义骨架方法其中某个步骤是protected子类重写这个步骤来改变算法细节。子类需要访问父类的内部状态比如父类有一个computeBaseSalary()方法子类要基于它做扩展这个方法就可以声明为protected。让子类重写某个方法如果父类的方法不想让外部任何人直接调用但希望子类可以重写用protected正好。引用我们前面的表格protected比较特殊的一点是它比默认修饰符“更开放”但不完全开放。同包的类能用它异包的子类也能用它。这意味着protected成员实际上会跟随继承关系暴露到另一个包里去——这也是它和默认修饰符最大的区别。但是注意protected成员在异包子类中访问时还有一个限制通过子类类型的引用来访问是允许的但通过父类类型的引用来访问却不一定允许。这其实是在问你在哪个包的哪个类里写代码。比如你在子类SavingsAccount里可以写this.balance假设balance是父类protected字段因为SavingsAccount是BankAccount的子类但你如果写BankAccount other new SavingsAccount(); other.balance;这在异包环境下会编译失败因为访问balance的代码在BankAccount类的外部而且此时引用类型是BankAccount不是SavingsAccount。这说起来有点绕实际工程里建议记住最简单的一条策略如果某个成员只是“给子类用的能力”优先考虑protected如果你只是想在同包内共享考虑默认修饰符。关于protected和默认到底怎么取舍我在第5.2节再展开。2.4 默认包私有Java里最容易被忽略的“第五种”很多人学Java的时候只记住了public、private、protected却忘了还有一个“默认”级别。当一个成员前面不写任何访问修饰符时它不是public也不是private而是“包私有”package-private也就是只有同一个包下的类能访问。这个级别很微妙。它的用途是同一包内的类之间共享细节比如一个model包里的多个类彼此需要协作但又不希望这些协作细节暴露给包外的代码。单元测试的便利很多团队会把测试类和被测类放在同一个包下比如com.example.service测试类就能直接访问被测类的包私有成员免去写public getter的麻烦。包级别的“内部工具类”一个util包内部可能有几个辅助类它们之间互相调用但不需要对外发布用默认修饰符就能控制住边界。不过默认修饰符有一个很现实的问题在Java里“包”这个粒度对工程结构来说有时候太大了。如果你把一大坨类全塞在同一个包下包私有几乎等于公开。所以在大型项目中我见过很多团队会明确要求除了测试统一用private和public默认修饰符要申请审批。原因是包边界不好维护类一多包私有就成了“半个public”而且是看不见的public容易失控。3. 实操环节设计一个可维护的BankAccount类理论说完了现在动手。我用一个真实的BankAccount类来演示怎么一步步给每个成员选对访问修饰符。3.1 需求拆解与修饰符规划假设需求如下账户有账号、余额、开户日期、利率可以存钱、取钱、查询余额取钱时余额不能为负每个月由系统批量结算利息利息金额要支持审计日志记录账户类型分为储蓄账户和信用账户信用账户允许透支一定额度。先别急着写代码把问题拆开字段给谁用账号、余额、开户日期属于“账户自身状态”外部只能读不能随便改所以私有字段 公开getter是稳妥的。利率这个东西子类可能要自己调整逻辑所以字段可以private但提供protected的方法给子类用。行为给谁用存钱、取钱是外部操作public余额查询public利息结算这个动作是系统内部批量任务在调但又需要子类可能重写所以是protected。审计日志是内部辅助private。构造策略用户要能创建账户所以构造函数public但为了让工厂方法统一管理也可以把构造设为private对外提供public static工厂方法——这是设计模式里“静态工厂”的玩法后面会提到。3.2 逐行实现为什么每个修饰符这么放下面是完整代码我加了很多注释来说明修饰符的取舍。package com.example.bank; import java.math.BigDecimal; import java.time.LocalDate; public class BankAccount { // 字段全部私有外部只能通过方法间接操作状态不会被绕过校验 private final String accountNo; private BigDecimal balance; private final LocalDate openDate; private BigDecimal annualInterestRate; // 构造函数public允许外部直接创建账户 public BankAccount(String accountNo, BigDecimal initialBalance, LocalDate openDate, BigDecimal annualInterestRate) { if (accountNo null || accountNo.isBlank()) { throw new IllegalArgumentException(账号不能为空); } this.accountNo accountNo; setBalanceInternal(initialBalance); this.openDate openDate; setAnnualInterestRate(annualInterestRate); } // 公开业务方法存钱 public void deposit(BigDecimal amount) { if (amount null || amount.compareTo(BigDecimal.ZERO) 0) { throw new IllegalArgumentException(存款金额必须大于0); } setBalanceInternal(this.balance.add(amount)); } // 公开业务方法取钱余额不能为负 public void withdraw(BigDecimal amount) { if (amount null || amount.compareTo(BigDecimal.ZERO) 0) { throw new IllegalArgumentException(取款金额必须大于0); } if (this.balance.subtract(amount).compareTo(BigDecimal.ZERO) 0) { throw new IllegalStateException(余额不足无法完成取款); } setBalanceInternal(this.balance.subtract(amount)); } // 公开方法查询余额 public BigDecimal getBalance() { return balance; } // 公开方法查询账号因为账号是final且初始化后不再变化直接返回即可 public String getAccountNo() { return accountNo; } // protected方法允许子类储蓄账户/信用账户在结算利息时重写 protected BigDecimal calculateMonthlyInterest() { return this.balance.multiply(annualInterestRate) .divide(BigDecimal.valueOf(12), 2, BigDecimal.ROUND_HALF_UP); } // protected方法月结允许同包系统任务调用也允许子类扩展 protected void applyMonthlySettlement() { BigDecimal interest calculateMonthlyInterest(); setBalanceInternal(this.balance.add(interest)); recordAuditLog(月结利息: interest); } // protected方法子类需要调整利率时使用 protected void setAnnualInterestRate(BigDecimal annualInterestRate) { if (annualInterestRate null || annualInterestRate.compareTo(BigDecimal.ZERO) 0) { throw new IllegalArgumentException(年利率不能为负数); } this.annualInterestRate annualInterestRate; } // private辅助方法统一走这个入口改余额方便打日志和做约束 private void setBalanceInternal(BigDecimal newBalance) { this.balance newBalance; } // private辅助方法审计日志仅供类内部调用 private void recordAuditLog(String message) { // 实际工程中这里可以写入日志文件或审计表 System.out.println([ LocalDate.now() ] accountNo message); } // 包私有方法给同一个包内的AuditService调用不对外暴露 void exportAuditData() { System.out.println(账号: accountNo , 余额: balance); } }这里有几个关键选择值得单独说明为什么balance不用public甚至不用protected因为一旦子类或外部直接能改balance那deposit、withdraw里的校验就全白写了。子类要改余额应该通过父类提供的protected方法比如applyMonthlySettlement来调度而不是直接碰字段。applyMonthlySettlement为什么是protected而不是public因为外部调用方应该只需要deposit、withdraw这样明确的业务动作而不需要知道“月结”这个内部流程。但同一个包下的MonthlyBatchJob类也要能触发它所以protected天然满足“同包可用、异包只有子类可用”这个需求。recordAuditLog为什么是private而不是protected因为审计日志的记录格式是内部实现细节子类不需要也不应该重写。如果哪天要把日志从控制台改成写文件只要保持private改动范围就在这一个类内部不会波及子类。3.3 用一段测试代码验证“访问边界”现在写一个同包测试类和异包测试类验证哪些能编译、哪些不能。package com.example.bank; public class SamePackageTester { public void test(BankAccount account) { account.getBalance(); // 编译通过public account.deposit(BigDecimal.TEN); // 编译通过public // account.balance ...; // 编译失败private字段 account.exportAuditData(); // 编译通过包私有SamePackageTester和BankAccount同包 // account.calculateMonthlyInterest(); // 编译失败protected且SamePackageTester不是子类 } }package com.example.other; import com.example.bank.BankAccount; public class OtherPackageTester { public void test(BankAccount account) { account.getBalance(); // 编译通过public account.deposit(BigDecimal.TEN); // 编译通过public // account.exportAuditData(); // 编译失败包私有成员异包不可见 // account.calculateMonthlyInterest(); // 编译失败protected非子类不可见 } }从这段测试可以直观看到public跨包畅通无阻包私有成员出了包就消失protected在异包非子类眼里也等于不存在。这也验证了前面那张关系表。实际开发中我建议每写一个新的类就顺手写一个同包测试类验证边界——不要只在脑子里面推演编译器的报错信息会帮你确认你的设计是否符合预期。4. 跨语言对比Java、C、C#、Python 有什么不一样很多人只学一门语言的时候对访问修饰符的认知是“理所当然”的。但一旦切到另一门语言就各种不适应Python里没有private关键字C的protected和Java还不完全一样C#默认的访问级别和Java也不同。这一节我把几门主流语言的差异梳理一遍。4.1 各语言访问控制体系横向对比语言关键字/机制默认访问级别典型坑Javapublic/protected/ 默认 /private包私有默认级别容易被人忽略Cpublic/protected/private可在类内分段标注private默认私有struct默认公有容易混淆C#public/protected/internal/protected internal/private默认privateinternal对应“程序集可见”概念和Java包私有不完全一样Python约定式_name受保护__name名字修饰默认公有没有真正的强制访问控制靠自觉TypeScriptpublic/protected/private默认public只做编译期检查运行时无强制这里重点展开几个容易出问题的点。C的struct/class默认级别。在C里struct和class唯一的区别就是默认访问级别struct默认是publicclass默认是private。很多从C转过来的人喜欢写struct结果里面全成了public。我的建议是明确写出访问级别不要依赖默认行为这样代码审阅的人一眼就能看到边界在哪里。Python的“下划线人文约定”。Python没有真正的访问修饰符所有的成员默认都是公开的外部都能访问。但业界约定俗成_name表示“受保护”子类可以用外部代码别碰__name会发生名字修饰name mangling类外访问会变成_ClassName__name但这只是挡君子不挡小人本质还是能访问到的。在这种没有强约束的语言里访问控制的意识尤其重要。你写_internal_cache这个字段如果你不遵守约定去外部访问它以后别人的代码就会依赖它——然后你重构的时候就是一场灾难。所以Python项目里制定并遵守访问约定比语言本身提供的语法更重要。C#的internal。C#有一个Java没有的internal级别描述的是“同一个程序集内可见”比“同一个包内可见”的粒度更大一些。很多大型.NET项目用internal来隐藏内部实现再配合InternalsVisibleTo给测试程序集开白名单。这个思路其实比Java的“包私有”更实用因为程序集边界和代码仓库结构往往更清晰地对应。4.2 从Java切到其他语言时的三个坑第一不要把Java的“默认包私有”思维带到C#里。C#成员默认是private不是像Java那样包私有所以你在C#里不写修饰符外部类直接就没法访问了。这个差异很隐蔽容易导致“我明明没写public怎么同事说访问不到”。第二不要把C的protected理解成Java的protected。在C里protected成员在子类中也是有访问限制的而且它和Java一样也允许“通过基类对象访问”的规则差异整体语法约束比Java严格更容易编译报错反而更不容易踩坑。第三不要以为TypeScript的private是安全边界。TypeScript的private只是编译期检查编译成JavaScript之后运行时没有任何强制手段属性照样可以访问。所以如果你要做真正的数据保护在TS里得靠闭包、WeakMap或者Symbol之类的机制但绝大多数项目并不会走这个极端——注意这是“约定”和“协作”层面的边界不是“安全”层面的边界。如果你和团队成员都能遵守约定TS的private已经够用了。4.3 按项目场景怎么选Java/C#后端业务系统字段一律private对外方法一律public少用默认级别protected只给真正需要扩展的“扩展点”用。C底层库能private就private需要子类扩展的用protected尽量少暴露public还要注意面向接口编程而不是直接暴露class。Python内部工具脚本约定优于语法_name表示内部实现不要依赖访问控制来解决架构问题依赖代码评审和约定更现实。TypeScript前端项目用private和protected明确表达设计意图但心里要清楚这只是“编码契约”不是“运行时保护”。5. 常见问题与排查技巧实录这部分我整理了几个我在实际开发中经常见到、也经常被问的问题按“问题-原因-排查建议”的方式列出来。每一个都是真实踩过的坑不是教科书里的假想场景。5.1 为什么子类访问不了父类的private字段这是最常见的问题连工作两三年的开发也偶尔会绕进去。你写了一个父类public class Animal { private String name; public Animal(String name) { this.name name; } } public class Dog extends Animal { public void printName() { System.out.println(name); // 编译失败name在Animal中是private } }为什么不行因为private的设计语义就是“只在声明它的类内部可见”。子类不是父类本身虽然它是父类的扩展但并不能因此访问父类的私有内脏。这是Java严格封装的一个体现子类只能继承父类“允许你继承”的部分。解决方案有四个把字段改成protected——如果确实需要子类直接访问提供protected或public的getter/setter——更推荐字段保持private行为可控提供protected的业务方法——如果你想让子类操作父类状态但必须走父类约束好的逻辑重新审视设计——子类经常需要直接操作父类的private字段可能意味着父类的职责划分有问题字段应该下沉到子类或者通过组合而不是继承。5.2 protected和默认到底差在哪表格再拿出来看一遍场景protected默认包私有同包同类可见可见同包子类可见可见同包非子类可见可见异包子类可见不可见异包非子类不可见不可见唯一的区别就在“异包子类”这一行。如果你的类不会被跨包继承那么protected和默认在实践中没有任何区别。因此取舍标准就很简单这个成员需要被“另一个包里的子类”使用吗你在写一个公共库你的BaseParser想允许“别人家的子类”重写tokenize()方法那必须protected。因为别人家的子类在另一个包默认级别会完全阻挡他们。你只是在同一个模块的多个包下内部协作子类都在同一个包内那用默认级别可以让边界更紧——将来就算有人乱继承也访问不到。我个人的经验是默认级别适合“同包内部协作的临时细节”比如一个service包里的两个类需要分享一个包级工具方法而protected是“面向继承的API”它本身就暗示了“我允许你来扩展”。所以从可读性角度protected比默认级别更有“表达力”看代码的人一眼就知道“这里允许子类介入”。5.3 字段到底该用private还是protected我的原则非常简单字段默认private除非你有一个很具体的、非用protected不可的理由否则一律private。为什么这么固执因为字段是“状态”状态是类最核心的部分。一旦你允许子类直接访问一个字段就等于允许子类绕过父类的方法来改变状态。父类维护的所有不变量比如“余额永远非负”“状态机只能按顺序流转”都会在子类这里失效。那什么时候可以破例当你明确知道这个字段“就是给子类用的而且子类应该直接操作它”的时候。比如一个框架类子类是用户自定义扩展点你要让他们直接往一个protected的集合里添加元素因为每次调用方法都要过一遍权限检查性能无法接受——这种性能或便利性上的强烈诉求才是用protected字段的合理理由。另外有一个折中方案推荐大家使用字段private方法protected。这样父类把操作字段的入口收拢在一个方法里子类通过重写方法来改变行为而数据本身始终由父类控制。这是模板方法模式的精髓也是我写可扩展类时最常用的一种设计。5.4 设计层面容易犯的错修饰符分配的逻辑混乱实际写代码中很多人给修饰符的分配是“随手”的比如哪个方法报错了就把private改成public哪个字段外部调不到了就改成protected。这种“逐步放宽”的路径非常危险——每一次放宽都是在增加未来重构的负担。我建议的分配顺序是先全部声明为private外部需要调用的方法改成public但要想清楚公开后是否便于演进子类需要重写或访问的改成protected默认级别只在“同包协作类之间明确共享”时使用且要有注释说明原因写完后再问自己一次这个成员真的有必要比private更开放吗这个过程走完你写出来的类的边界就会清晰很多。如果你发现一个类有一大堆protected成员可能是你在过度设计继承结构如果有一大堆public方法可能是这个类的职责太大该拆分了。6. 一些个人的实操心得最后分享几点从项目里总结出来的经验不算系统理论但很实用。6.1 访问修饰符不是用来“防黑客”的我一直和团队讲不要指望靠private来防恶意攻击反射可以绕过访问检查序列化可以绕过构造函数这些都非常容易。访问修饰符的真正价值是建立团队成员之间的协作契约——它告诉后来人我设计这个类的时候默认你只需要用这些public方法其他都是可以随时变化的内部细节。明白了这一点你就不会在“这个字段要不要设成私有”上犹豫半天了。优先级很清晰先确保它能保护不变量再考虑使用便利性。如果一个公开的getter会导致某个内部状态被外部依赖那我们宁可先不暴露它直到确实有需求出现。6.2 写类的时候从“外部视角”反推修饰符很多初学者是“写字段 - 写方法 - 顺手标修饰符”这样往往会把所有字段都标成public。我个人的习惯是“先定义外部该干什么再定义内部怎么隐藏”。具体做法拿张纸或者在注释里写清楚这个类的使用手册外部调用方允许做什么比如deposit、withdraw、getBalance。哪些是内部实现细节比如余额校验、日志记录、利率换算。哪些是子类扩展点比如月结利息计算。把这三个清单列出来修饰符就自动浮现了使用手册上的标public内部细节标private扩展点标protected。这个过程不需要考虑太久关键在于先想清楚设计意图不要再纠结语法。6.3 配套使用public API越少越好我工作这么多年一个非常深刻的体会是类的public方法数量是衡量其设计质量的最直观指标之一。public方法越多类的表面积越大和你这个类耦合的代码就越多将来重构就越痛苦。因此每次加一个public方法之前我都会先问自己三个问题这个方法的调用方是谁现在和将来都有明确的需求吗有没有可能用更少的公开方法满足同样需求这个方法改名或者改参数会造成多大的影响范围这三个问题问完很多原本想公开的方法最终都变成了private或者直接删掉。这让我写的类的接口越来越小、越来越稳定后续需求变化时不需要整天改别人的调用代码。6.4 小技巧利用编译器的报错反向检查设计最后分享一个我经常用的小技巧。写完一个类之后我会尝试在另外一个包里写一段测试代码故意访问这个类的各个成员。编译器会明确报出哪些不可见这些报错信息等价于一张“访问边界检查报告”。比如我本来想让calculateMonthlyInterest()被子类重写但忘了加protected它默认是包私有的。那么异包子类重写时必然编译报错编译器会提醒我“method does not override or implement a method from a supertype”。看到这个报错我就会意识到哦这个方法是意图成为扩展点的应该改成protected。这种“用编译器当设计审查工具”的做法几乎零成本却能帮我在写代码的时候就发现访问级别的失误不用等到代码评审阶段再被同事抓包。你们下次写完类可以试试。访问修饰符这东西说难不难说简单也不简单。它背后牵涉的是面向对象设计中最核心的封装思想。你越早理解“访问修饰符不是语法负担而是设计工具”写出来的代码就越容易维护。希望这篇文章能帮你把这个工具用顺手。
1. 访问修饰符到底是什么从一个“失控”的类讲起先别急着背定义。我直接说一个很多初级工程师都干过的事写了一个User类字段全部用public然后业务代码里到处直接操作字段比如user.age -1、user.passwordHash whatever。等上了生产环境数据烂掉了你想约束这些赋值行为结果所有地方都在改牵一发动全身根本不敢动。这个场景我见过太多次了。说白了访问修饰符Access Modifiers不是语法层面的“装饰品”它是Java、C、C#这类面向对象语言里用来控制类成员“谁可以碰、谁不能碰”的一套边界系统。它解决的核心问题不是“防止别人恶意攻击”而是“防止你自己在三个月后手滑或者团队里其他人误用你写的类”。这篇文章适合谁看如果你是刚学完对象、继承、多态正要进入“怎么设计一个像样的类”阶段的初学者那正合适如果你写了两年业务代码但对protected和默认修饰符的区别始终模模糊糊也可以当一次系统性的复习。我会用Java为主来讲解同时把C、Python、C#这些常用语言的差异放在一起对比——毕竟现在很多人是跨语言开发的只懂一套规则很容易踩坑。1.1 先看一个没有访问修饰符的“事故现场”假设我们写一个BankAccount银行账户类用来记录余额。如果完全不设访问控制public class BankAccount { public double balance; public String ownerName; }然后业务代码里这么写BankAccount account new BankAccount(); account.balance -500; // 直接赋负值没有任何校验这段代码能编译、能运行但显然不合理。余额可以是负数但在真实的银行系统里提现、透支的规则应该是明确的业务逻辑而不是一个裸字段随便让人改。一旦这样的代码上线后续任何一次需求变更——比如“余额不能低于-1000”——你都得满项目去搜索哪个地方改了balance然后一个一个改。这就是没有访问修饰符的代价所有字段像广场一样任何人、任何时候都能进来踩一脚。访问修饰符的第一层意义就是“把字段关起来”强制要求外部代码通过方法行为来操作数据把数据校验、状态流转的规则收敛到类内部。1.2 核心价值封装、契约、安全往深一层说访问修饰符四个字背后站着的是面向对象三大特性里的“封装”。封装不是让你把代码藏起来不给人看而是明确两个东西类对外提供什么——这是公共契约别人能调用你的公开方法类内部保留什么——这是实现细节将来怎么改都不会影响调用方。公共契约一旦定了你内部怎么做都行。比如BankAccount.deposit(double amount)方法对外承诺“存钱”内部是存数据库还是写文件外部不关心。但如果外部可以直接修改balance字段那么“存钱”这个行为逻辑就被架空了契约形同虚设。从安全角度讲访问修饰符还能防止一些危险操作比如把passwordHash声明为public导致任何代码都能读甚至改密码哈希把init()这种一次性初始化方法声明为public导致运行途中别人能随时再调一次状态被重置。这些都不是“黑客攻击”问题而是“自己人误操作”问题——在实际工程中后者才是主要矛盾。1.3 先把四个级别的关系图刻在脑子里Java的访问修饰符从小到大排列访问级别同包同类同包子类同包非子类异包子类异包非子类private可以不可以不可以不可以不可以默认包私有可以可以可以不可以不可以protected可以可以可以可以不可以public可以可以可以可以可以建议把这张表抄在笔记本上这是整个访问修饰符体系最核心的一张表。后面所有疑问几乎都可以回到这张表来推导。注意关键差异点private只有定义这个成员的类自己能用。默认也叫包私有同一个包内的所有类都能用出了包就不行了。protected同包随便用异包的子类也能用。public谁都能用。这四个等级本质上是从最封闭到最开放的连续光谱。设计类的时候你的任务就是找对每个成员在这个光谱上的位置。2. 四个访问修饰符逐一拆解从最开放到最封闭2.1 public开放的公共接口public是四个修饰符里最“大方”的一个声明了它就意味着这个成员是类对外的接口面。正常情况下应该只用在下列场合对外提供服务的业务方法比如deposit()、withdraw()、getBalance()类本身要能被外部实例化所以构造函数通常也是public实现接口的方法接口方法默认就是public abstract你实现时也只能是public。但有一个高频误用把字段直接声明为public。除非是常量比如public static final int MAX_AMOUNT 50000;否则字段设计成public基本都是设计缺陷。原因我在前面说过字段没法做校验也没法在赋值时触发额外逻辑。你可能会想“我加个注释让别人别乱改不就行了”——想法太天真人的记忆是不可靠的总有一天会有人绕过你的注释。另外从演进角度看public是代价最高的修饰符。一旦你发布了这个类外界已经有人在你public方法的基础上写代码了那么这个方法后续想改签名、改行为就都受限制了。Java生态里有个著名的“破坏性变更”现象很多库升级一个小版本就因为一个public方法的行为微调导致下游大面积编译失败。你暴露出去的public越多你未来重构的自由度就越低。2.2 private类内专属谁也别想碰private是四个里最严格的只有声明它的类自己能访问子类、同包兄弟类、外部类统统不行。它为“封装”提供了最强的保障。我们通常要求字段用private除非有特殊理由所有实例字段都应该是private外部只能通过getter/setter或业务方法间接访问。辅助方法用private有些方法是纯内部实现细节比如拆分计算过程、格式化内部数据结构这些方法没理由暴露出去应该private。常量可以例外private static final你在类内部用目的是不让外部依赖这个常量值未来改值不影响外部。有一个细节经常被忽略private成员在同类内部是随便访问的包括“同类不同对象”。这句话什么意思看代码public class Person { private String name; public boolean sameName(Person other) { return this.name.equals(other.name); } }sameName方法里this.name是私有的没问题other.name同样是private字段但因为访问方是Person类自身所以照样能拿。很多初学者以为“私有字段只有当前这个对象能访问”其实是“只有当前这个类能访问”——不管对象是this还是另一个实例只要是这个类的代码就能访问private成员。这个理解偏差在实际代码里经常引发困惑。2.3 protected为继承而生的“半开放”protected的设计初衷很明确让子类能继承和使用父类的部分内部能力但对外部世界保持封闭。典型的使用场景是模板方法模式父类定义骨架方法其中某个步骤是protected子类重写这个步骤来改变算法细节。子类需要访问父类的内部状态比如父类有一个computeBaseSalary()方法子类要基于它做扩展这个方法就可以声明为protected。让子类重写某个方法如果父类的方法不想让外部任何人直接调用但希望子类可以重写用protected正好。引用我们前面的表格protected比较特殊的一点是它比默认修饰符“更开放”但不完全开放。同包的类能用它异包的子类也能用它。这意味着protected成员实际上会跟随继承关系暴露到另一个包里去——这也是它和默认修饰符最大的区别。但是注意protected成员在异包子类中访问时还有一个限制通过子类类型的引用来访问是允许的但通过父类类型的引用来访问却不一定允许。这其实是在问你在哪个包的哪个类里写代码。比如你在子类SavingsAccount里可以写this.balance假设balance是父类protected字段因为SavingsAccount是BankAccount的子类但你如果写BankAccount other new SavingsAccount(); other.balance;这在异包环境下会编译失败因为访问balance的代码在BankAccount类的外部而且此时引用类型是BankAccount不是SavingsAccount。这说起来有点绕实际工程里建议记住最简单的一条策略如果某个成员只是“给子类用的能力”优先考虑protected如果你只是想在同包内共享考虑默认修饰符。关于protected和默认到底怎么取舍我在第5.2节再展开。2.4 默认包私有Java里最容易被忽略的“第五种”很多人学Java的时候只记住了public、private、protected却忘了还有一个“默认”级别。当一个成员前面不写任何访问修饰符时它不是public也不是private而是“包私有”package-private也就是只有同一个包下的类能访问。这个级别很微妙。它的用途是同一包内的类之间共享细节比如一个model包里的多个类彼此需要协作但又不希望这些协作细节暴露给包外的代码。单元测试的便利很多团队会把测试类和被测类放在同一个包下比如com.example.service测试类就能直接访问被测类的包私有成员免去写public getter的麻烦。包级别的“内部工具类”一个util包内部可能有几个辅助类它们之间互相调用但不需要对外发布用默认修饰符就能控制住边界。不过默认修饰符有一个很现实的问题在Java里“包”这个粒度对工程结构来说有时候太大了。如果你把一大坨类全塞在同一个包下包私有几乎等于公开。所以在大型项目中我见过很多团队会明确要求除了测试统一用private和public默认修饰符要申请审批。原因是包边界不好维护类一多包私有就成了“半个public”而且是看不见的public容易失控。3. 实操环节设计一个可维护的BankAccount类理论说完了现在动手。我用一个真实的BankAccount类来演示怎么一步步给每个成员选对访问修饰符。3.1 需求拆解与修饰符规划假设需求如下账户有账号、余额、开户日期、利率可以存钱、取钱、查询余额取钱时余额不能为负每个月由系统批量结算利息利息金额要支持审计日志记录账户类型分为储蓄账户和信用账户信用账户允许透支一定额度。先别急着写代码把问题拆开字段给谁用账号、余额、开户日期属于“账户自身状态”外部只能读不能随便改所以私有字段 公开getter是稳妥的。利率这个东西子类可能要自己调整逻辑所以字段可以private但提供protected的方法给子类用。行为给谁用存钱、取钱是外部操作public余额查询public利息结算这个动作是系统内部批量任务在调但又需要子类可能重写所以是protected。审计日志是内部辅助private。构造策略用户要能创建账户所以构造函数public但为了让工厂方法统一管理也可以把构造设为private对外提供public static工厂方法——这是设计模式里“静态工厂”的玩法后面会提到。3.2 逐行实现为什么每个修饰符这么放下面是完整代码我加了很多注释来说明修饰符的取舍。package com.example.bank; import java.math.BigDecimal; import java.time.LocalDate; public class BankAccount { // 字段全部私有外部只能通过方法间接操作状态不会被绕过校验 private final String accountNo; private BigDecimal balance; private final LocalDate openDate; private BigDecimal annualInterestRate; // 构造函数public允许外部直接创建账户 public BankAccount(String accountNo, BigDecimal initialBalance, LocalDate openDate, BigDecimal annualInterestRate) { if (accountNo null || accountNo.isBlank()) { throw new IllegalArgumentException(账号不能为空); } this.accountNo accountNo; setBalanceInternal(initialBalance); this.openDate openDate; setAnnualInterestRate(annualInterestRate); } // 公开业务方法存钱 public void deposit(BigDecimal amount) { if (amount null || amount.compareTo(BigDecimal.ZERO) 0) { throw new IllegalArgumentException(存款金额必须大于0); } setBalanceInternal(this.balance.add(amount)); } // 公开业务方法取钱余额不能为负 public void withdraw(BigDecimal amount) { if (amount null || amount.compareTo(BigDecimal.ZERO) 0) { throw new IllegalArgumentException(取款金额必须大于0); } if (this.balance.subtract(amount).compareTo(BigDecimal.ZERO) 0) { throw new IllegalStateException(余额不足无法完成取款); } setBalanceInternal(this.balance.subtract(amount)); } // 公开方法查询余额 public BigDecimal getBalance() { return balance; } // 公开方法查询账号因为账号是final且初始化后不再变化直接返回即可 public String getAccountNo() { return accountNo; } // protected方法允许子类储蓄账户/信用账户在结算利息时重写 protected BigDecimal calculateMonthlyInterest() { return this.balance.multiply(annualInterestRate) .divide(BigDecimal.valueOf(12), 2, BigDecimal.ROUND_HALF_UP); } // protected方法月结允许同包系统任务调用也允许子类扩展 protected void applyMonthlySettlement() { BigDecimal interest calculateMonthlyInterest(); setBalanceInternal(this.balance.add(interest)); recordAuditLog(月结利息: interest); } // protected方法子类需要调整利率时使用 protected void setAnnualInterestRate(BigDecimal annualInterestRate) { if (annualInterestRate null || annualInterestRate.compareTo(BigDecimal.ZERO) 0) { throw new IllegalArgumentException(年利率不能为负数); } this.annualInterestRate annualInterestRate; } // private辅助方法统一走这个入口改余额方便打日志和做约束 private void setBalanceInternal(BigDecimal newBalance) { this.balance newBalance; } // private辅助方法审计日志仅供类内部调用 private void recordAuditLog(String message) { // 实际工程中这里可以写入日志文件或审计表 System.out.println([ LocalDate.now() ] accountNo message); } // 包私有方法给同一个包内的AuditService调用不对外暴露 void exportAuditData() { System.out.println(账号: accountNo , 余额: balance); } }这里有几个关键选择值得单独说明为什么balance不用public甚至不用protected因为一旦子类或外部直接能改balance那deposit、withdraw里的校验就全白写了。子类要改余额应该通过父类提供的protected方法比如applyMonthlySettlement来调度而不是直接碰字段。applyMonthlySettlement为什么是protected而不是public因为外部调用方应该只需要deposit、withdraw这样明确的业务动作而不需要知道“月结”这个内部流程。但同一个包下的MonthlyBatchJob类也要能触发它所以protected天然满足“同包可用、异包只有子类可用”这个需求。recordAuditLog为什么是private而不是protected因为审计日志的记录格式是内部实现细节子类不需要也不应该重写。如果哪天要把日志从控制台改成写文件只要保持private改动范围就在这一个类内部不会波及子类。3.3 用一段测试代码验证“访问边界”现在写一个同包测试类和异包测试类验证哪些能编译、哪些不能。package com.example.bank; public class SamePackageTester { public void test(BankAccount account) { account.getBalance(); // 编译通过public account.deposit(BigDecimal.TEN); // 编译通过public // account.balance ...; // 编译失败private字段 account.exportAuditData(); // 编译通过包私有SamePackageTester和BankAccount同包 // account.calculateMonthlyInterest(); // 编译失败protected且SamePackageTester不是子类 } }package com.example.other; import com.example.bank.BankAccount; public class OtherPackageTester { public void test(BankAccount account) { account.getBalance(); // 编译通过public account.deposit(BigDecimal.TEN); // 编译通过public // account.exportAuditData(); // 编译失败包私有成员异包不可见 // account.calculateMonthlyInterest(); // 编译失败protected非子类不可见 } }从这段测试可以直观看到public跨包畅通无阻包私有成员出了包就消失protected在异包非子类眼里也等于不存在。这也验证了前面那张关系表。实际开发中我建议每写一个新的类就顺手写一个同包测试类验证边界——不要只在脑子里面推演编译器的报错信息会帮你确认你的设计是否符合预期。4. 跨语言对比Java、C、C#、Python 有什么不一样很多人只学一门语言的时候对访问修饰符的认知是“理所当然”的。但一旦切到另一门语言就各种不适应Python里没有private关键字C的protected和Java还不完全一样C#默认的访问级别和Java也不同。这一节我把几门主流语言的差异梳理一遍。4.1 各语言访问控制体系横向对比语言关键字/机制默认访问级别典型坑Javapublic/protected/ 默认 /private包私有默认级别容易被人忽略Cpublic/protected/private可在类内分段标注private默认私有struct默认公有容易混淆C#public/protected/internal/protected internal/private默认privateinternal对应“程序集可见”概念和Java包私有不完全一样Python约定式_name受保护__name名字修饰默认公有没有真正的强制访问控制靠自觉TypeScriptpublic/protected/private默认public只做编译期检查运行时无强制这里重点展开几个容易出问题的点。C的struct/class默认级别。在C里struct和class唯一的区别就是默认访问级别struct默认是publicclass默认是private。很多从C转过来的人喜欢写struct结果里面全成了public。我的建议是明确写出访问级别不要依赖默认行为这样代码审阅的人一眼就能看到边界在哪里。Python的“下划线人文约定”。Python没有真正的访问修饰符所有的成员默认都是公开的外部都能访问。但业界约定俗成_name表示“受保护”子类可以用外部代码别碰__name会发生名字修饰name mangling类外访问会变成_ClassName__name但这只是挡君子不挡小人本质还是能访问到的。在这种没有强约束的语言里访问控制的意识尤其重要。你写_internal_cache这个字段如果你不遵守约定去外部访问它以后别人的代码就会依赖它——然后你重构的时候就是一场灾难。所以Python项目里制定并遵守访问约定比语言本身提供的语法更重要。C#的internal。C#有一个Java没有的internal级别描述的是“同一个程序集内可见”比“同一个包内可见”的粒度更大一些。很多大型.NET项目用internal来隐藏内部实现再配合InternalsVisibleTo给测试程序集开白名单。这个思路其实比Java的“包私有”更实用因为程序集边界和代码仓库结构往往更清晰地对应。4.2 从Java切到其他语言时的三个坑第一不要把Java的“默认包私有”思维带到C#里。C#成员默认是private不是像Java那样包私有所以你在C#里不写修饰符外部类直接就没法访问了。这个差异很隐蔽容易导致“我明明没写public怎么同事说访问不到”。第二不要把C的protected理解成Java的protected。在C里protected成员在子类中也是有访问限制的而且它和Java一样也允许“通过基类对象访问”的规则差异整体语法约束比Java严格更容易编译报错反而更不容易踩坑。第三不要以为TypeScript的private是安全边界。TypeScript的private只是编译期检查编译成JavaScript之后运行时没有任何强制手段属性照样可以访问。所以如果你要做真正的数据保护在TS里得靠闭包、WeakMap或者Symbol之类的机制但绝大多数项目并不会走这个极端——注意这是“约定”和“协作”层面的边界不是“安全”层面的边界。如果你和团队成员都能遵守约定TS的private已经够用了。4.3 按项目场景怎么选Java/C#后端业务系统字段一律private对外方法一律public少用默认级别protected只给真正需要扩展的“扩展点”用。C底层库能private就private需要子类扩展的用protected尽量少暴露public还要注意面向接口编程而不是直接暴露class。Python内部工具脚本约定优于语法_name表示内部实现不要依赖访问控制来解决架构问题依赖代码评审和约定更现实。TypeScript前端项目用private和protected明确表达设计意图但心里要清楚这只是“编码契约”不是“运行时保护”。5. 常见问题与排查技巧实录这部分我整理了几个我在实际开发中经常见到、也经常被问的问题按“问题-原因-排查建议”的方式列出来。每一个都是真实踩过的坑不是教科书里的假想场景。5.1 为什么子类访问不了父类的private字段这是最常见的问题连工作两三年的开发也偶尔会绕进去。你写了一个父类public class Animal { private String name; public Animal(String name) { this.name name; } } public class Dog extends Animal { public void printName() { System.out.println(name); // 编译失败name在Animal中是private } }为什么不行因为private的设计语义就是“只在声明它的类内部可见”。子类不是父类本身虽然它是父类的扩展但并不能因此访问父类的私有内脏。这是Java严格封装的一个体现子类只能继承父类“允许你继承”的部分。解决方案有四个把字段改成protected——如果确实需要子类直接访问提供protected或public的getter/setter——更推荐字段保持private行为可控提供protected的业务方法——如果你想让子类操作父类状态但必须走父类约束好的逻辑重新审视设计——子类经常需要直接操作父类的private字段可能意味着父类的职责划分有问题字段应该下沉到子类或者通过组合而不是继承。5.2 protected和默认到底差在哪表格再拿出来看一遍场景protected默认包私有同包同类可见可见同包子类可见可见同包非子类可见可见异包子类可见不可见异包非子类不可见不可见唯一的区别就在“异包子类”这一行。如果你的类不会被跨包继承那么protected和默认在实践中没有任何区别。因此取舍标准就很简单这个成员需要被“另一个包里的子类”使用吗你在写一个公共库你的BaseParser想允许“别人家的子类”重写tokenize()方法那必须protected。因为别人家的子类在另一个包默认级别会完全阻挡他们。你只是在同一个模块的多个包下内部协作子类都在同一个包内那用默认级别可以让边界更紧——将来就算有人乱继承也访问不到。我个人的经验是默认级别适合“同包内部协作的临时细节”比如一个service包里的两个类需要分享一个包级工具方法而protected是“面向继承的API”它本身就暗示了“我允许你来扩展”。所以从可读性角度protected比默认级别更有“表达力”看代码的人一眼就知道“这里允许子类介入”。5.3 字段到底该用private还是protected我的原则非常简单字段默认private除非你有一个很具体的、非用protected不可的理由否则一律private。为什么这么固执因为字段是“状态”状态是类最核心的部分。一旦你允许子类直接访问一个字段就等于允许子类绕过父类的方法来改变状态。父类维护的所有不变量比如“余额永远非负”“状态机只能按顺序流转”都会在子类这里失效。那什么时候可以破例当你明确知道这个字段“就是给子类用的而且子类应该直接操作它”的时候。比如一个框架类子类是用户自定义扩展点你要让他们直接往一个protected的集合里添加元素因为每次调用方法都要过一遍权限检查性能无法接受——这种性能或便利性上的强烈诉求才是用protected字段的合理理由。另外有一个折中方案推荐大家使用字段private方法protected。这样父类把操作字段的入口收拢在一个方法里子类通过重写方法来改变行为而数据本身始终由父类控制。这是模板方法模式的精髓也是我写可扩展类时最常用的一种设计。5.4 设计层面容易犯的错修饰符分配的逻辑混乱实际写代码中很多人给修饰符的分配是“随手”的比如哪个方法报错了就把private改成public哪个字段外部调不到了就改成protected。这种“逐步放宽”的路径非常危险——每一次放宽都是在增加未来重构的负担。我建议的分配顺序是先全部声明为private外部需要调用的方法改成public但要想清楚公开后是否便于演进子类需要重写或访问的改成protected默认级别只在“同包协作类之间明确共享”时使用且要有注释说明原因写完后再问自己一次这个成员真的有必要比private更开放吗这个过程走完你写出来的类的边界就会清晰很多。如果你发现一个类有一大堆protected成员可能是你在过度设计继承结构如果有一大堆public方法可能是这个类的职责太大该拆分了。6. 一些个人的实操心得最后分享几点从项目里总结出来的经验不算系统理论但很实用。6.1 访问修饰符不是用来“防黑客”的我一直和团队讲不要指望靠private来防恶意攻击反射可以绕过访问检查序列化可以绕过构造函数这些都非常容易。访问修饰符的真正价值是建立团队成员之间的协作契约——它告诉后来人我设计这个类的时候默认你只需要用这些public方法其他都是可以随时变化的内部细节。明白了这一点你就不会在“这个字段要不要设成私有”上犹豫半天了。优先级很清晰先确保它能保护不变量再考虑使用便利性。如果一个公开的getter会导致某个内部状态被外部依赖那我们宁可先不暴露它直到确实有需求出现。6.2 写类的时候从“外部视角”反推修饰符很多初学者是“写字段 - 写方法 - 顺手标修饰符”这样往往会把所有字段都标成public。我个人的习惯是“先定义外部该干什么再定义内部怎么隐藏”。具体做法拿张纸或者在注释里写清楚这个类的使用手册外部调用方允许做什么比如deposit、withdraw、getBalance。哪些是内部实现细节比如余额校验、日志记录、利率换算。哪些是子类扩展点比如月结利息计算。把这三个清单列出来修饰符就自动浮现了使用手册上的标public内部细节标private扩展点标protected。这个过程不需要考虑太久关键在于先想清楚设计意图不要再纠结语法。6.3 配套使用public API越少越好我工作这么多年一个非常深刻的体会是类的public方法数量是衡量其设计质量的最直观指标之一。public方法越多类的表面积越大和你这个类耦合的代码就越多将来重构就越痛苦。因此每次加一个public方法之前我都会先问自己三个问题这个方法的调用方是谁现在和将来都有明确的需求吗有没有可能用更少的公开方法满足同样需求这个方法改名或者改参数会造成多大的影响范围这三个问题问完很多原本想公开的方法最终都变成了private或者直接删掉。这让我写的类的接口越来越小、越来越稳定后续需求变化时不需要整天改别人的调用代码。6.4 小技巧利用编译器的报错反向检查设计最后分享一个我经常用的小技巧。写完一个类之后我会尝试在另外一个包里写一段测试代码故意访问这个类的各个成员。编译器会明确报出哪些不可见这些报错信息等价于一张“访问边界检查报告”。比如我本来想让calculateMonthlyInterest()被子类重写但忘了加protected它默认是包私有的。那么异包子类重写时必然编译报错编译器会提醒我“method does not override or implement a method from a supertype”。看到这个报错我就会意识到哦这个方法是意图成为扩展点的应该改成protected。这种“用编译器当设计审查工具”的做法几乎零成本却能帮我在写代码的时候就发现访问级别的失误不用等到代码评审阶段再被同事抓包。你们下次写完类可以试试。访问修饰符这东西说难不难说简单也不简单。它背后牵涉的是面向对象设计中最核心的封装思想。你越早理解“访问修饰符不是语法负担而是设计工具”写出来的代码就越容易维护。希望这篇文章能帮你把这个工具用顺手。
