PHP封装的本质是“定规矩”而非“锁起来”，通过public、protected、private明确访问边界，并以getter/setter承载业务校验，类型化属性（PHP 7.4+）强化运行时约束。
封装不是“锁起来”，而是“定规矩”
PHP封装的本质不是阻止访问，而是明确谁能在什么场景下怎么访问。它靠 public、protected、private 三个修饰符划出三道边界，每道边界对应一套调用规则。理解封装最直接的方式，是把它当成类对外发布的“接口说明书”：哪些能直接用，哪些只能子类用，哪些连子类都不让碰——全写在修饰符里了。
常见错误现象：Fatal error: Cannot access private property User::$password 或 Cannot access protected property，这类报错不是代码写错了，而是你试图绕过说明书去翻别人家抽屉。
-
public属性/方法：没加修饰符默认就是它，类内外、子类都能直接读写或调用 -
protected：只允许本类和继承它的子类内部使用$this访问，外部对象哪怕用->也进不去 -
private：仅限当前类内部，子类重写同名属性/方法时，彼此完全隔离，互不可见
为什么必须配 getter/setter，不能只加 private？
只把属性设为 private 是半截封装——它拦住了非法赋值，但也拦死了合法需求。真正的封装要提供可控的入口，也就是 getXXX() 和 setXXX() 方法。它们不是形式主义，而是业务逻辑的落脚点。
使用场景举例：用户年龄不能为负数、密码必须加密后再存、用户名需过滤空格和特殊字符……这些校验都得塞进 setAge() 或 setName() 里，而不是放任外部直接 $user->age = -5。
立即学习“PHP免费学习笔记（深入）”；
- 不带校验的
private $age+ 直接赋值，等于装了锁却把钥匙焊死在门上 - 带校验的
private $age+setAge(int $age)，才是既防乱改，又保可用 - PHP 7.4+ 支持类型声明，
private int $age能在运行时自动拦截非整数，但依然无法替代业务层判断（比如年龄=200）
__get() 和 __set() 不是封装捷径，而是兜底方案
这两个魔术方法常被误当作“给 private 属性开后门”的便利工具，实际它们是动态访问的兜底机制，适用场景非常有限：比如构建通用配置类、ORM 属性代理、或兼容旧代码。滥用会破坏封装意图，让校验逻辑失控。
容易踩的坑：__set() 里不做类型或范围检查，等同于把 private 形同虚设；更危险的是在 __get() 中返回敏感数据（如数据库连接句柄），而没意识到它会被任何外部代码无条件触发。
- 需要严格控制的字段（如
$password），绝不该依赖__set()做唯一校验 - 如果类里大量属性都走
__get/__set，说明设计已偏离封装本意——应拆分职责或明确定义访问契约 - IDE 和静态分析工具对魔术方法支持弱，过度使用会降低可维护性
PHP 7.4+ 类型化属性让封装更实在
以前写 private $count，谁都可能传个字符串进来；现在写 private int $count，PHP 运行时直接抛 TypeError，不用等业务逻辑跑完才发现问题。这不是语法糖，是封装从“靠人自觉”走向“靠引擎兜底”的关键升级。
性能与兼容性影响：类型声明本身无运行时开销，但要求 PHP ≥ 7.4。若项目还跑在 7.3 或更早版本，强行加类型会直接导致解析失败。
- 标量类型（
int、string、bool）和array在 7.4 全面支持 - 自定义类类型（如
private Logger $logger）可强化依赖契约，但要注意循环引用风险 - 类型声明 +
private是目前最简练、最安全的封装组合，比纯靠注释或文档约束可靠得多
真正难的不是写对 private 或 setXXX()，而是每次加一个属性前，想清楚它该暴露多少、谁需要改、改的时候必须满足什么条件——封装的复杂点永远在业务边界上，不在语法上。
