用户类核心字段（如$id、$email、$passwordhash）应声明为private，仅在需子类复用或框架强制时用protected；__get/__set非万能补丁，密码等敏感字段须专用setter并禁用getter，状态变更须封装为带副作用的方法。
PHP 用户类封装是否合理，关键不在于用不用 private，而在于「哪些字段必须隔离」「哪些逻辑必须收口」「哪些变更需要可控传播」。直接暴露属性或全靠魔术方法兜底，都会在后续迭代中埋雷。
用户类属性该用 private 还是 protected？
绝大多数情况下，用户核心字段（如 $id、$email、$passwordHash）必须声明为 private。不是为了“看起来更面向对象”，而是避免子类或外部代码绕过校验逻辑直接赋值。
常见错误现象：
- 子类中直接写
$this->email = 'xxx';，跳过邮箱格式验证 - 测试时 mock 对象后强行改
$user->status = 'banned'，但没触发封禁钩子
只有两类情况可考虑 protected：
- 父类定义通用行为，子类需复用并微调（例如
User→AdminUser共享$lastLoginAt但各自处理刷新逻辑） - 框架强制要求（如 Laravel 的 Eloquent 模型某些属性需
protected才能被批量赋值识别）
__get() 和 __set() 不是万能补丁
用魔术方法自动代理所有属性访问，看似省事，实则破坏封装契约。它让类失去对字段读写的主动权，也掩盖了真正需要控制的边界。
典型问题：
-
__set('email', 'invalid@')不报错，但后续save()才失败，错误定位延迟 - 无法对
$password写入做单向哈希，因为__set接收到的是明文，而你不知道调用方意图是设新密码还是迁移旧数据 - IDE 和静态分析工具无法推断属性类型，
$user->name在 PHPStan 中变成 mixed
建议只在明确需要动态属性（如扩展字段存储）时用魔术方法，用户主干字段必须显式定义 getName() / setName() 等方法，并在其中嵌入业务规则。
密码字段必须走专用 setter
$password 是最典型的“不可读、只可写（且带转换）”字段。它不该有 getPassword()，也不该允许通过 __get 读取原始哈希值。
正确做法：
- 属性声明为
private string $passwordHash; - 提供
changePassword(string $plain): void，内部调用password_hash() - 提供
verifyPassword(string $plain): bool，封装password_verify() - 构造函数中禁止接收明文密码，除非明确标记为
forMigration()这类特殊场景
如果业务需要“重置密码时发邮件”，那这个动作应由 requestPasswordReset() 方法触发，而不是暴露 $resetToken 属性任由外部设置。
状态字段要绑定生命周期约束
像 $status（active / pending / banned）、$emailVerified 这类字段，不能只是存个布尔或字符串。它们的变更往往牵扯事件、日志、权限回滚等副作用。
容易踩的坑：
- 直接
$user->status = 'banned';，但没记录操作人、没通知管理员、没清理 session - 前端传
{ status: "pending" }更新用户，后端无校验就入库，导致状态非法跃迁（如从banned直接回到pending）
解决方案是把状态变更做成方法：
ban(string $reason, ?int $adminId = null): voidverifyEmail(): void-
deactivate(): void（而非开放setStatus()）
每个方法内集中处理校验、副作用、审计日志。这样哪怕未来加风控策略，也只改一个地方。
封装真正的难点不在语法，而在判断“这个值变更是单纯存数据，还是代表一次业务动作”。一旦混淆，private 也挡不住逻辑泄露。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
