protected变量不能在类外部直接访问，仅限当前类及其子类访问；子类可访问父类protected成员，但兄弟类或无关类不可；需通过getter/setter暴露数据，且从public改为protected属破坏性变更。
protected 变量不能在类外部直接访问
PHP 的 protected 修饰符明确拒绝类外部（包括实例化对象后）的直接读写。这不是语法限制松动的问题，而是访问控制的硬边界。
常见错误现象：Fatal error: Cannot access protected property MyClass::$name —— 即使你写了 $obj->name，也会立刻报错，不给任何商量余地。
- 子类内部可以自由访问父类的
protected属性和方法，这是它和private的核心区别 - 类外部哪怕用反射（
ReflectionProperty）强行读取，也属于绕过设计意图，不推荐用于常规逻辑 - 如果需要对外暴露数据，应该提供
public的 getter/setter 方法，而不是降级为public
protected 在继承链中只对“当前类及其子类”生效
它的作用域不是“整个继承树”，而是“声明该属性的类 + 所有直接/间接子类”。一旦跨出这个层级，比如兄弟类之间、子类的子类调用祖父类的 protected 成员（但未被中间类重写或暴露），就可能踩坑。
使用场景：你想让子类能复用或扩展某个状态，但又不希望被无关类篡改 —— protected 就是为此存在。
立即学习“PHP免费学习笔记（深入）”；
- 父类定义
protected $config，子类 A 和子类 B 都能读写它，但 A 无法访问 B 的实例上的同名属性（哪怕类型一样） - 如果子类重写了父类的
protected属性（PHP 8.2+ 允许类型声明变更，但不允许多重定义），原父类逻辑可能失效 - 注意 trait 中的
protected成员：被 use 进类后，行为等同于该类自己声明的protected，不受 trait 所在命名空间影响
var_dump / print_r 看不到 protected 属性值？不是 bug 是设计
var_dump() 和 print_r() 默认会显示 protected 属性，但会在属性名前后加上 *\0 字节（如 \0*\0name）。这容易让人误以为“没输出”或“被过滤了”，其实是 PHP 序列化格式的一部分。
性能影响很小，但调试时若依赖字符串匹配去 grep 属性名，就会漏掉 —— 因为 \0 是不可见字符。
- 用
get_object_vars($obj)获取不到protected或private属性，它只返回public的 - 想安全遍历所有属性（含 protected），得用
ReflectionObject+getProperties(ReflectionProperty::IS_PROTECTED) - JSON 编码（
json_encode()）默认忽略protected和private，除非类实现了JsonSerializable
从 public 改成 protected 是破坏性变更
这不是语义微调，而是接口收缩。所有原本通过对象箭头操作符直接读写的代码都会立即中断。
兼容性影响比想象中大：框架的自动映射（如 Laravel 的 Model 属性填充）、序列化工具、甚至某些 IDE 的自动补全都可能依赖 public 属性的可访问性。
- 如果你在重构旧代码，先全局搜索
$obj->xxx形式对该属性的所有调用点 - 不要只改声明，必须同步补上
getXXX()/setXXX()，并确保 setter 里做必要校验（protected不代表“可信输入”） - 测试覆盖要包含子类访问路径 —— 有时子类里看似正常的写法，其实在父类升级后触发了意外的 visibility 冲突
最常被忽略的一点：protected 不提供线程安全或并发保护，也不阻止运行时动态添加属性（$obj->newProp = 'xxx' 依然合法，但它会是 public 的）。它的约束只发生在编译/解析阶段，且仅限于显式声明的成员。
