Beego点赞评论需优先设计合理数据模型与接口粒度：点赞用联合唯一索引防重复，禁用前端状态判断；Redis缓存点赞数须INCRBY+EXPIRE防雪崩；评论分页应改用游标分页替代Limit/Offset。
Beego 里做点赞评论互动，核心不是“加功能”，而是选对数据模型和接口粒度——否则并发点踩、重复提交、缓存不一致会立刻暴露。
点赞接口必须带幂等性校验
直接用 POST /api/article/:id/like 接收用户 ID 并写库，大概率导致重复点赞（比如用户手抖连点两次、前端没禁用按钮、网络重试）。Beego 默认不处理幂等，得自己拦。
- 在 Controller 中先查
Like表：用UserId+ArticleId联合唯一索引，查不到才插入；查到了就返回200 OK且{"liked": true} - 别依赖前端传来的
is_liked状态做判断——它可能过期或伪造；后端只认数据库当前记录 - 如果用 Redis 缓存点赞数，记得用
INCRBY+EXPIRE组合，避免缓存雪崩时 DB 被打穿
评论列表分页不能只靠 ORM 的 Limit/Offset
Beego 的 orm.QuerySeter 支持 Limit 和 Offset，但当评论量上万、用户翻到第 100 页时，OFFSET 5000 会导致 MySQL 全表扫描，响应明显变慢。
- 改用游标分页（cursor-based）：按
created_at DESC, id DESC排序，前端传上次最后一条的created_at和id，SQL 加WHERE created_at - Beego 中拼条件用
qs.Filter("created_at__lt", cursorTime).Filter("id__lt", cursorId)不够安全，建议手写原生 SQL 配合o.Raw() - 务必给
(article_id, created_at, id)建联合索引，否则游标查询也慢
Beego 的 Session 在点赞/评论时容易被忽略的坑
很多人用 beego.GlobalSessionManager.SessionStart 拿 session，但默认配置下 session 过期时间短、存储在内存里，多实例部署时用户行为会错乱（比如 A 实例里点了赞，B 实例查不到 session 用户状态）。
- 必须显式配置 session 存储为
redis：在conf/app.conf里设session.provider = redis和session.providerconfig = "127.0.0.1:6379" - 检查
session.maxlifetime是否 ≥ 3600（至少一小时），否则用户刚登录完就点不了赞 - 不要在中间件里用
sess := context.Input.CruSession后直接sess.Destroy()—— Beego 的 session 销毁是延迟的，下次请求仍可能读到旧值
真正难的不是写完接口，而是当 50 个用户同时刷同一篇文章时，点赞数是否准确、最新评论是否顺序正确、Redis 和 DB 的状态是否始终一致。这些细节在本地跑不通问题，压测时才爆出来。
