public成员类内外均可访问；protected仅限本类及子类内部；private严格限定于定义它的类内部，连子类也不可访问，违反将触发Fatal error。
public、protected、private 到底谁能在哪调用？
结论很直接：只有 public 成员能从类外部直接访问；protected 只能在本类和子类内部用；private 严格限定在定义它的那个类内部，连子类都碰不到。
这不是“写不写得通”的问题，而是 PHP 解析器强制执行的访问控制——试图越界访问会直接报 Fatal error: Cannot access private/protected property 或类似错误。
-
public：类内、子类、类外（new 出来的对象）全都能读写属性、调用方法 -
protected：类内 ✔️；子类 ✔️（可用$this->xxx）；类外 ❌（$obj->xxx会挂） -
private：仅限定义它的那个类内部 ✔️；子类和类外一律 ❌（哪怕名字一样、继承关系再深也不行）
为什么不能在子类里直接用父类的 private 属性？
因为 private 的作用域不是“整个继承链”，而是“单个类体”。它和 protected 的关键区别就在这儿——很多人误以为“private 在子类里只是不能直接访问，但能通过父类 public 方法间接用”，这没错，但根源是：PHP 把 private 当作“这个类自己的私密数据”，不参与任何继承可见性传递。
比如父类 A 有个 private $log，子类 B extends A 中写 $this->log = 'x'，运行时直接报错，不是警告，是中断执行。
立即学习“PHP免费学习笔记（深入）”；
- 想让子类安全使用，改用
protected - 若必须保留
private，只能靠父类提供public或protected的 setter/getter - 别指望魔术方法
__get/__set能绕过private访问限制——它们只对不可见的public属性或不存在的属性触发，对private属性无效
什么时候该用 protected 而不是 public？
当你希望子类能复用或扩展某个能力，但又不希望外界随意修改或调用时，protected 就是那个“半开的门”。典型场景是模板方法模式、钩子方法、内部状态缓存等。
例如框架中常见：protected function beforeSave()，供子类重写，但不允许控制器层直接调用；或者 protected $cache，子类可读写，但 API 返回对象时不会暴露它。
- 滥用
public会导致耦合变高——外部代码依赖了本不该暴露的实现细节 - 过度用
private会让继承变得僵硬，子类想微调逻辑都得复制粘贴整段逻辑 -
protected是封装与可扩展之间的实际平衡点，不是“折中”，而是有明确设计意图的选择
var 声明属性等于 public？别信旧资料了
PHP 5.0 之前允许用 var $name，它确实等价于 public $name，但这是历史遗留语法。PHP 7.4+ 已弃用，PHP 8.0+ 会报 Deprecated: Using "var" for properties is deprecated。现在必须显式写 public、protected 或 private。
更关键的是：没写修饰符的属性或方法，在 PHP 中不是默认 public，而是语法错误——解析失败，根本跑不起来。
- 别依赖 IDE 自动补全的
var，关掉相关模板或手动删掉 - 检查老项目时，遇到
var要立刻替换，否则升级 PHP 版本后会崩 - 静态分析工具（如 PHPStan）会把缺失修饰符当作严重问题标出，不是警告，是 error 级别
最容易被忽略的一点：访问修饰符影响的不只是“能不能访问”，还决定着序列化行为、反射结果、以及某些 ORM 或测试框架的属性探测逻辑。比如 private 属性在 serialize() 后仍保留，但 ReflectionClass::getProperties() 默认不返回它——除非你显式传 ReflectionProperty::IS_PRIVATE。这些边界情况，往往在调试深拷贝或单元测试 mock 时才突然冒出来。
