封装要求属性私有、方法公有，以实现受控访问；反向操作破坏校验统一性与继承安全；__get/__set非理想替代，应优先手写明确的getter/setter方法。
PHP封装中属性和方法的可见性可以独立设置
能。PHP的public、protected、private修饰符是按成员（属性或方法）逐个声明的，属性封装与否，完全不影响方法的访问控制方式——两者互不绑定。
常见错误：以为“封装类”就必须全部私有化
新手容易把“封装”理解成“整个类都要藏起来”，结果写出这种代码：
class User {
private $name;
private $email;
private function validateEmail() { /* ... */ }
private function save() { /* ... */ }
}
这导致外部连new User()后都无法调用任何方法，对象失去可用性。封装不是“锁死”，而是“有选择地暴露”。
- 属性设为
private，是为了防止直接赋值绕过校验（比如$u->age = -5） - 方法设为
public，恰恰是为了提供受控的入口（如$u->setAge(25)） - 内部辅助方法（如
validateEmail）才适合private——它本就不该被外部感知
为什么推荐属性私有 + 方法公有（而非相反）
反向操作（属性public、关键方法private）会破坏封装本质：
立即学习“PHP免费学习笔记（深入）”；
- 如果
$user->email可直接读写，那private function isValidEmail()就形同虚设 - 业务逻辑分散：校验可能在构造函数、setter、save方法里重复写，难以统一维护
- 子类继承时，
protected属性+public方法组合更灵活；而public属性一旦暴露，子类就无法拦截或转换
PHP 7.4+ 的类型声明进一步强化了这个模式：private string $name; + public function getName(): string 是标准搭配。
真正要注意的坑：__get/__set不是万能替代方案
有人用__get/__set魔术方法“假装封装”，但实际效果很危险：
-
__set无法对每个属性做差异化校验（比如email要正则，age要范围检查），最终往往退化成透传 - IDE 和静态分析工具（如 PHPStan）无法识别魔术方法的语义，类型提示失效
-
isset($obj->privateProp)默认返回false，必须手动实现__isset，否则逻辑出错
除非是极简 DTO 或配置类，否则优先手写明确的getXXX/setXXX方法——名字即契约，改起来也清楚。
最易被忽略的一点：protected属性在继承链中看似“折中”，但一旦子类直接修改$this->data，父类的不变量（invariant）就崩了。真要留给子类扩展，用protected方法钩子（如beforeSave）比protected属性安全得多。
