用map和结构体可快速搭建go评分模型：movie用map[string]movie，rating用map[int64][]rating，配sync.rwmutex；movie.id用string、rating.score用float32；calculateaveragescore需判空并用float64累加，结果保留一位小数；http接口须校验jwt用户id、防重复提交；sqlite需手动启用外键、日期存iso8601格式。
用 map 和结构体快速搭建评分核心模型
Go 里没有内置的“关系型内存数据库”，但电影评分系统初期完全不需要 ORM 或外部 DB。用 map[string]*Movie 存电影，map[int64][]*Rating 按用户 ID 存评分，再加一个 sync.RWMutex 控制并发读写，就能跑通 90% 的基础逻辑。
关键点在于结构体字段设计要预留扩展性：
-
Movie.ID建议用string（兼容 IMDb ID、TMDB ID 等外部源） -
Rating.Score用float32而非int，避免后续想支持半星评分时重构 - 别把用户昵称、头像等信息塞进
Rating结构体——评分行为本身只依赖UserID和MovieID
CalculateAverageScore() 必须处理空评分和浮点精度
调用 CalculateAverageScore("tt1234567") 返回 0.0 不一定代表电影没评分，可能是没人评过，也可能是所有评分都是 0。必须显式区分：
- 先查
ratingsByMovieID["tt1234567"]是否为nil或空切片 → 返回0.0并设valid: false - 累加时用
float64(sum)避免float32累加误差（尤其评分超千条时） - 最终结果用
math.Round(score*10) / 10保留一位小数，而不是fmt.Sprintf("%.1f", score)—— 后者是字符串截断，不是数值四舍五入
HTTP 接口设计要防重复提交和越权操作
RESTful 路由如 POST /movies/{id}/rating 看似合理，但实际会遇到两个硬伤：
立即学习“go语言免费学习笔记（深入）”；
- 用户 A 可能伪造请求给用户 B 的评分记录加数据 → 必须从 JWT token 或 session 中提取真实
userID，**忽略 URL 或 body 里的user_id字段** - 前端连点两次“打5分”可能生成两条重复评分 → 在存库前查
ratingExists(userID, movieID)，存在则用UPDATE语义覆盖，而非INSERT - 别用
http.Error()直接返回 400，对客户端不友好；统一返回 JSON：{"error": "rating already exists", "code": "duplicate_rating"}
SQLite 做持久化时注意外键与时间戳格式
当数据量超过 10 万条或需要多表关联（比如用户资料、电影分类），该切 SQLite。但 Go 的 database/sql 驱动默认不启用外键约束：
- 建表后必须执行
PRAGMA foreign_keys = ON，否则ON DELETE CASCADE不生效 - 电影上映日期建议存为
TEXT格式"2023-05-12"（ISO8601），别用INTEGER时间戳 —— 方便 SQL 查询（如WHERE release_date > '2020-01-01'） - Go 写入时用
time.Time值直接 Scan/Exec 即可，驱动会自动转成字符串；但记得在structtag 里加db:"created_at"，别依赖字段名大小写匹配
真正麻烦的从来不是“怎么存”，而是“什么时候从内存切到磁盘”——冷启动加载全量评分进 map 可能卡顿 2 秒，这时候就得考虑按热度分片懒加载，或者直接上 Redis 缓存热榜。
