应使用HSET分字段存储用户资料而非SET存JSON，因其支持原子性单字段操作、避免并发覆盖、节省带宽；字段名须全小写下划线；慎用HGETALL防性能陷阱；Hash无内置TTL，需显式EXPIRE。
用 HSET 存字段，别用 SET 存整个 JSON
直接把用户资料序列化成 JSON 用 SET 存，看似简单，但改头像、改昵称就得反序列化→修改→再序列化→重写整条记录。不仅浪费带宽，还可能在并发时丢更新（比如两个请求同时读旧 JSON、各自改一个字段、再写回去，其中一个改动就没了）。
HSET 把每个字段当独立子项存进 Hash，天然支持单字段增删改查：
HSET user:10086 nickname "阿哲" avatar_url "/avatars/10086.png" age 28
- 只改昵称？
HSET user:10086 nickname "阿哲2号"，其他字段完全不动 - 新增字段？直接加，比如
HSET user:10086 bio "前端搬砖人" - 字段不存在？自动创建；已存在？原地覆盖，原子性有保障
字段名别带空格或特殊符号，统一小写下划线
Redis 的 Hash 字段名本质是字符串，但实际使用中会频繁拼接、校验、日志打印。如果字段名是 "user_name" 和 "userName" 混用，或者出现 "first name"（带空格），后续用 Lua 脚本或客户端批量操作时容易出错，排查起来也费劲。
- 推荐命名：
nickname、email_verified、last_login_at - 避免：
"Nick Name"、userEmail（驼峰和下划线混用）、created-at（连字符在某些客户端解析异常） - 所有字段名全小写+下划线，和数据库字段习惯对齐，也方便 ORM 或中间层映射
注意 HGETALL 的性能陷阱：大 Hash 别随便全量拉
用户资料字段少时，HGETALL user:10086 拿全部字段没问题。但如果后期加了 settings_json、notification_prefs 这类长文本字段，Hash 可能膨胀到几 KB，甚至上百 KB。每次 HGETALL 都要序列化全部字段、网络传输、客户端解析——延迟陡增，还浪费内存。
- 只读昵称和头像？用
HMGET user:10086 nickname avatar_url显式指定字段 - 后台管理页需要全量？可以接受，但得确认该场景确实需要，别让前端“顺手”调
HGETALL当默认行为 - 字段数超 20 个或预估体积 > 4KB，就要警惕——考虑是否该拆分，比如把大字段单独用
SET存，用 Hash 只管轻量元数据
过期时间不能直接设在 Hash 上，得靠 EXPIRE 单独设
Hash 是 Redis 的复合结构，它本身不支持设置 TTL；你对 user:10086 执行 HSET，不会继承任何过期逻辑。想让整个用户资料自动过期，必须额外调一次 EXPIRE：
HSET user:10086 nickname "阿哲" age 28<br>EXPIRE user:10086 3600
- 漏掉
EXPIRE？这个 Hash 就永久存在，哪怕用户注销了也不会自动清理 - 更新字段后要不要重设过期？要看业务逻辑：如果是登录态续期，应该
EXPIRE user:10086 3600再刷一次；如果只是改个签名，通常不用动 TTL - 用
HEXISTS判断字段是否存在时，不会触发过期检查；真正触发删除是在下次访问该 key 时——所以TTL user:10086返回 -2 表示已过期且被清除，-1 表示没设过期
Hash 结构本身很干净，但字段粒度更新的便利性，恰恰依赖你对命令边界和生命周期的清醒认知——比如过期不是自动附着的，字段名不是随便起的，全量读取也不是无代价的。这些地方一松懈，后期就容易变成缓存雪球。
