选 gin：其中间件生态更适配社交场景的读多写少、高连接数特点，context 设计利于 jwt 鉴权、请求 id 注入与限流熔断，且 redis 集成调试更便捷。
用 gin 还是 echo 搭建社交 API 服务？
选框架不是看 Star 数，而是看中间件生态和并发模型是否匹配社交场景的读多写少、高连接数特点。gin 的 Context 设计更利于统一处理 JWT 鉴权、请求 ID 注入、限流熔断；echo 的 echo.Group 分组路由对模块化（如 /api/v1/posts、/api/v1/friends）更直观。实际项目中，若需快速集成 redis 做在线状态或消息队列，gin 的中间件链式写法更易调试。
注意：gin.Default() 自带日志和恢复中间件，但生产环境必须替换 gin.Recovery() 为自定义 panic 处理——否则用户发个非法 JSON 就可能暴露服务路径或堆栈。
用户关系（关注/粉丝/黑名单）怎么用 GORM 建模才不卡？
别直接用 gorm.HasMany 嵌套查粉丝列表，一次请求可能触发 N+1 查询。核心表结构要拆开：users（主键 id）、follows（复合唯一索引 user_id, follow_id），并加覆盖索引 idx_follow_status（user_id, follow_id, status）支持「互关检测」和「拉黑隔离」。
-
status字段用 tinyint（0=正常，1=已拉黑，2=已取关），避免删行导致外键断裂 - 查某用户所有关注者时，用
db.Table("follows").Where("user_id = ? AND status = 0", userID).Select("follow_id").Rows()，绕过 GORM 模型层减少内存拷贝 - 双向关系（如 A 关注 B 后，B 的「新粉丝通知」）必须走异步任务，别在事务里调
http.Post
实时消息用 WebSocket 还是 Server-Sent Events？
WebSocket 是必须的，但别自己实现连接管理。用 gorilla/websocket 时，关键不是升级握手，而是连接生命周期控制：SetReadDeadline 和 SetWriteDeadline 必须设，否则空闲连接会堆积；CloseNotify() 已废弃，改用 ctx.Done() 配合 net.Conn.SetReadBuffer(4096) 控制粘包。
立即学习“go语言免费学习笔记（深入）”；
典型坑：websocket.Upgrader.CheckOrigin 默认返回 false，本地开发不设 func(r *http.Request) bool { return true } 会导致跨域失败，但上线后必须严格校验 Origin，否则可被钓鱼站点伪造连接。
通知类消息（如点赞、评论）建议用 SSE 推送摘要，再由前端按需拉取详情——比全量 WebSocket 更省服务端资源。
图片上传和缩略图生成怎么避免阻塞 HTTP 请求？
别在 HTTP handler 里调 github.com/disintegration/imaging 做同步裁剪。流程必须拆成：接收原图 → 存 OSS/MinIO → 发送 MQ 消息（含 file_id, width, height）→ 独立 worker 进程消费并生成缩略图 → 回写数据库 thumbnails 表。
上传接口本身只做三件事：multipart.ParseMultipartForm 限制最大内存（如 32MB）、io.Copy 流式写入临时文件、计算 sha256 防重复。缩略图尺寸策略要前置约定：头像固定 200x200，动态封面用 800x450，不接受运行时传参，否则容易被恶意构造超大尺寸拖垮 CPU。
MinIO 的 PutObject 调用要加 context timeout，且 opts.ServerSideEncryption 开启，否则用户上传的私密照片可能明文落盘。
