HashedCast 不是 Laravel 官方支持的类型转换类，密码哈希应通过 setPasswordAttribute 修改器在写入时调用 Hash::make() 实现，而非自定义 cast；验证时必须使用 Hash::check()。
HashedCast 不是 Laravel 官方提供的内置类型转换类，Laravel 本身没有 HashedCast 这个 cast。你看到的“Eloquent Hashed Casting”很可能是混淆了两个独立机制：密码哈希（用 Hash::make()） 和 Eloquent 属性类型转换（casts 数组）。
真正安全、标准、被 Laravel 官方支持的做法是：在模型保存前手动哈希密码，而不是靠 cast 自动完成。原因很实在——哈希必须是单向、不可逆、带盐的，而 cast 的 get/set 是对称逻辑，不适合也不该承担这个职责。
setPasswordAttribute 是处理密码哈希的正确入口
这是最常用也最可控的方式，直接在模型中定义修改器，确保每次赋值 password 字段时都走哈希流程：
- 修改器只在设置值时触发，不干扰读取（数据库存的是哈希串，读出来就是哈希串，本就不该解密）
- 可以明确控制是否跳过哈希（比如种子数据或测试场景加条件判断）
- 避免把哈希逻辑耦合进
casts，后者更适合 JSON、日期、布尔等无状态转换
public function setPasswordAttribute($value)
{
if (! empty($value)) {
$this->attributes['password'] = \Illuminate\Support\Facades\Hash::make($value);
}
}-
Hash::make()默认用 bcrypt，自动加盐并嵌入哈希结果中 - 如果字段允许为空（如第三方登录用户无密码），
if (! empty($value))能防止空字符串被哈希成有效哈希值 - 不要在这里调用
Hash::check()—— 那是验证阶段的事，不是存储阶段
为什么不能用 casts + 自定义 HashedCast 类？
即使你手写一个实现 CastsAttributes 的类，在 set 里调 Hash::make()，也会踩几个坑：
立即学习“PHP免费学习笔记（深入）”；
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
-
casts机制会在所有写入场景触发，包括updateOrCreate()、批量更新、fill()、甚至模型事件中的属性赋值 —— 很难精准控制何时该哈希、何时不该（比如管理员重置密码 vs 同步外部用户数据） -
casts的get方法必须返回值，但密码字段绝不该提供“解哈希”能力；若留空get，又会导致 API 返回 null 或原始哈希串，容易误暴露 - Laravel 的迁移、Factory、Seeder 等工具不感知自定义 cast 的 set 行为，可能绕过哈希直接写明文
所以，官方文档和实际项目中，99% 的密码处理都落在 setPasswordAttribute，而不是 casts。
登录时验证密码必须用 Hash::check()，不能自己比对字符串
数据库里存的是类似 $2y$10$abc... 的 bcrypt 哈希串，它包含算法标识、成本因子、盐和密文。直接用 === 或 strcmp() 比对明文和哈希串毫无意义：
-
Hash::check('plain', $hashed)会自动提取盐，用相同参数重新哈希明文，再比对结果 - 它还能兼容未来升级的算法（比如从 bcrypt 切到 Argon2），只要配置在
config/hashing.php里，代码不用改 - 必须配合 try-catch？不必要。
Hash::check()对非法哈希格式会静默返回false，不会抛异常 —— 异常只发生在Hash::make()输入超长等极端情况
if (Hash::check($request->password, $user->password)) {
// 允许登录
}别写成 password_verify() —— 那是原生 PHP 函数，Laravel 的 Hash 门面已封装并做了增强（比如自动适配不同算法、更严格的输入校验）。
关键点其实就一个：哈希是写入时的强制预处理动作，不是数据类型的“转换”。把它当成业务规则（像“邮箱必须小写”“手机号去空格”）来守，而不是当成 JSON 或 datetime 那样的格式桥接。漏掉修改器、误用 cast、或在 get 里尝试“反哈希”，都是线上事故的常见起点。
