private字段不对外暴露，所有读写必须经getter/setter，新增字段需同步补全对应方法及类型校验，否则导致调用失败或数据不一致。
private 字段改了，为什么 getter/setter 全得跟着动？
因为 private 字段本身不对外暴露，所有读写都必须走你写的 getXXX() 和 setXXX() 方法。一旦新增字段，比如加个 private string $status;，你就得同步补上 getStatus()、setStatus(string $status)，否则外部代码根本没法用——这不是“忘了写”，是封装机制强制要求的接口对齐。
常见错误现象：Attempt to read property "status" on object 或调用 $user->setStatus() 报 Call to undefined method，本质都是字段和接口没配对。
- PHP 7.4+ 支持属性类型声明，
private string $status;写完后，setStatus()的参数类型也得匹配string，否则运行时报TypeError - 如果旧逻辑里已有状态校验（比如只允许
'active'/'inactive'），新setStatus()里就得复刻这套判断，否则数据一致性就破了 - 构造函数里要不要初始化这个字段？如果业务上它不能为空，就得在
__construct()里强制传参或设默认值，否则对象一创建就是脏状态
protected 字段看似省事，其实埋雷更隐蔽
protected 字段允许子类直接访问，看起来比 private 灵活，但正因如此，它把校验和约束逻辑分散到了各个子类里。新增字段时，你不仅要改父类，还得逐个检查所有子类是否用了这个字段、有没有绕过校验直接赋值。
使用场景：适合真正需要被继承扩展的内部状态，比如一个基类 BaseService 里存 protected array $config;，子类可自由读写；但如果你新加的是业务强约束字段（如 $dueDate），protected 就等于放弃控制权。
- 子类里直接写
$this->dueDate = '2026-12-31';，完全跳过日期格式校验 - IDE 和静态分析工具（如 PHPStan）对
protected字段的类型推断弱于private+ 显式方法，容易漏掉类型错误 - 重构时不敢轻易改字段名——你不知道哪个子类在某个角落里硬编码引用了它
public 字段为什么不是“捷径”，而是技术债务加速器？
直接声明 public string $status;，确实不用写 getter/setter，新增字段秒完成。但代价是：任何地方都能无条件改值，$user->status = 'xxx'; 后你完全不知道这个值是否合法、有没有触发关联逻辑（比如状态变更是不是该发通知？）、甚至是不是拼错了字段名（$user->stauts 不报错，只是静默失效）。
PHP 8.3 已默认禁用动态属性，但 public 字段仍被允许——这恰恰让它成了最危险的“合法漏洞”。团队协作中，新人看到 public 就以为“随便改”，结果改出数据不一致。
- 无法在赋值时做转换（比如把字符串
'1'自动转成整型1） - 无法触发监听或日志（比如每次改
$status都要记录变更历史） - 单元测试难覆盖：你没法 mock 一个 public 字段的行为，只能测最终效果，路径分支爆炸
字段新增时，最容易被忽略的兼容性点
封装不是写完就完的事，关键是让老代码不崩、新需求能接。很多“牵一发而动全身”其实卡在向下兼容上，而不是语法层面。
- 数据库迁移没同步：加了
private int $priority;，但表里没加priority字段，__construct()从 DB 结果集赋值时直接 Notice - JSON 序列化失效：没重写
jsonSerialize()，新增private字段不会进 API 返回，前端突然发现字段消失 - 反序列化失败：用
unserialize()恢复旧对象时，PHP 会把未知字段丢进$this->__properties（PHP 7.4+），但你的__wakeup()没处理，字段值永远为 null - ORM 映射断开：Laravel Eloquent 或 Doctrine 要求
$fillable或@ORM\Column显式声明，漏了就存不进库
真正的复杂点不在“怎么加字段”，而在“加完之后，哪些地方会因为没走你设计的接口路径而悄悄失效”。这类问题往往上线后才暴露，且难以复现。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
