golang如何实现用户订阅偏好管理_golang用户订阅偏好管理实现总结-Golang-PHP中文网

应使用独立的 user_preferences 表存储动态偏好，以 json 字段支持灵活扩展、区分“未设置”与“显式关闭”，并通过乐观锁和事务封装避免并发覆盖。

golang如何实现用户订阅偏好管理_golang用户订阅偏好管理实现总结

直接存数据库字段不是不行，但硬编码 email_newsletter、push_promo 这类布尔字段会快速失控——加个新渠道就得改表、改 struct、改所有 CRUD 逻辑。真正可持续的做法是把“偏好”当独立资源建模。

用一张 user_preferences 表，字段至少包含：user_id（外键）、preference_key（如 "weekly_digest"）、value（JSON 或布尔/字符串，推荐 JSON）、updated_at
Go struct 不要嵌套一堆 bool 字段，而是用 map[string]json.RawMessage 或自定义类型（如 type Preference map[string]interface{}）承载动态键值
避免用 sql.NullBool 存每个偏好——它无法表达“未设置”和“明确关闭”的区别，而业务上这两者常需不同处理

看似多一次序列化/反序列化，实则换来关键灵活性：新增偏好无需 DDL 变更，灰度发布时可对部分用户写入新 key，老代码读不到就忽略，不会 panic。

value 字段类型选 JSON（PostgreSQL/MySQL 5.7+）或 TEXT（需手动 json.Marshal/json.Unmarshal），别用 BOOLEAN 或 VARCHAR(10)
注意 PostgreSQL 的 JSONB 支持索引，但 Go 的 json.RawMessage 写入前必须确保是合法 JSON，否则 INSERT 会报 "invalid input syntax for type json"
不要在 JSON 里存复杂结构（如嵌套 map + slice 混用），前端解析容易出错；简单扁平对象足够，例如：{"enabled": true, "frequency": "daily", "channels": ["email", "web"]}

用户可能在 App 和网页端同时修改偏好，两个请求都读旧值 → 各自计算新值 → 同时写回，后到的会覆盖先到的变更。这不是 Go 特有问题，但 Go 的默认 HTTP handler 容易让人忽略事务边界。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

用 UPDATE ... WHERE user_id = ? AND updated_at = ? 做乐观锁，失败时重试（最多 3 次），别直接 UPDATE ... SET value = ? WHERE user_id = ? AND preference_key = ?
如果用 Redis 缓存偏好，务必和 DB 更新放在同一事务中（或用延时双删），否则出现 "已关闭推送但依然收到通知" 这类典型不一致
避免在 HTTP handler 里直接调 db.Exec —— 把更新逻辑封装进 service 方法，强制传入 context.Context 和 *sql.Tx，让调用方控制事务生命周期

多数人只测“开/关”，但真实场景下有三个状态：未设置（null）、显式开启、显式关闭——尤其“未设置”常被当成 false，导致新用户收不到欢迎邮件。

单元测试必须覆盖 GetPreference("sms_alerts") 返回 nil 的情况，而不是假设它一定返回 bool
集成测试里插入一条只有 user_id 和 preference_key 的记录（value 为 NULL），验证读取逻辑是否 panic 或静默转成 false
检查 SQL 查询是否用了 LEFT JOIN 或 COALESCE —— 直接 JOIN 会丢掉未设置任何偏好的用户，导致他们无法看到偏好设置页的默认选项