Eloquent 中不存在“Attribute Security States”或security_states属性，这是对$hidden、访问器、casts和Policy等机制的误读；实际安全需组合使用字段隐藏、动态脱敏、类型转换与策略授权。
Eloquent 的 “Attribute Security States” 并不是 Laravel 官方概念，也没有 security_states 这个内置属性或机制 —— 这是常见误解，源于对模型访问器（accessors）、强制转换（casts）、隐藏字段（$hidden）、可见字段（$visible）以及策略（Policies）的混合误读。
为什么搜不到 security_states？
Laravel 文档、源码、Eloquent 核心类（如 Model、HasAttributes）中均无 security_states 属性或方法。它不属于 Eloquent 的语法、生命周期钩子或安全模块。如果你在某篇“教程”里看到这个词，大概率是作者自造术语，把字段可见性控制 + 策略授权 + 访问器逻辑强行打包命名的结果。
实际开发中，真正起作用的是以下几组明确、分离、可验证的机制：
-
$hidden和$visible：控制 JSON 序列化时哪些字段出现（仅影响toArray()/toJson()，不防数据库读取） -
get*Attribute()访问器：可动态过滤、脱敏或拒绝返回敏感值（例如把password_hash转成"***"） -
casts：确保类型安全（如把数据库里的json自动转为数组），但不提供访问控制 - Policy +
Gate::allows()：在业务逻辑层做细粒度授权（比如“用户只能看自己的 email”，不能靠模型字段配置实现）
如何安全地暴露/隐藏模型字段？
别依赖不存在的“安全状态”，直接用 Laravel 原生字段控制组合：
立即学习“PHP免费学习笔记（深入）”；
class User extends Model
{
// 永远不序列化的字段（即使调用 toArray() 也不出现）
protected $hidden = ['password', 'remember_token', 'api_token'];
// 只有显式指定时才出现在数组中（慎用，易遗漏）
protected $visible = ['id', 'name', 'email'];
// 动态脱敏：访问 email 时，非本人或管理员则返回掩码
protected function getEmailAttribute($value)
{
if (! auth()->check() || (! auth()->user()->is_admin && auth()->id() !== $this->id)) {
return '***@***.***';
}
return $value;
}
}
注意：$hidden 对 Eloquent 查询本身无效 —— 如果你写 User::select('email')->first()，email 依然会被查出来，只是不会出现在 JSON 输出里。真正的数据隔离必须靠查询约束（where('user_id', auth()->id())）或 Policy。
Policy 才是真正的“安全状态”执行者
字段级访问控制必须下沉到授权层，而非模型配置。例如：
// app/Policies/UserPolicy.php
public function viewEmail(User $user, User $target): bool
{
return $user->id === $target->id || $user->is_admin;
}
然后在控制器里显式检查：
if (Gate::denies('viewEmail', $user)) {
abort(403);
}
// 此时才能放心返回 $user->email
不调用 Gate 或 can()，光靠模型上的 $hidden 或访问器，根本挡不住 API 直接调用或关系预加载（with('profile')）带来的越权风险。
容易被忽略的关键点
很多人以为设置 $hidden = ['password'] 就万事大吉，但实际漏洞常出在这些地方：
- 使用
DB::table('users')->select('email')->get()绕过模型，$hidden完全失效 - 在 API Resource 里忘了调用
only()或手动过滤，把敏感字段又塞回响应体 - 关系模型（如
Post关联的User）未限制 eager loading 的字段，导致post->user->password被意外访问（即使User::$hidden存在，也只对User实例本身生效） - 访问器里没做身份校验就返回默认值（比如所有用户看到的都是
"***@***.***"），反而泄露了“该字段存在且有值”这一元信息
安全不是加个配置项就能开启的状态，而是从查询构造、模型实例化、资源转换到响应输出的每一步都需主动防御。所谓“Attribute Security States”，其实是你亲手写出来的 Policy、Resource 和 accessor 的组合效果 —— 没有捷径，也没有魔法开关。
