Gin更适配照片墙接口需求：其高性能Radix树路由与稳定Context封装（如c.FormFile）优于net/http的原始繁琐和Echo的上传偶发丢帧；分页须弃用LIMIT OFFSET，改用created_at+id游标分页并仅查关键字段防内存溢出。
为什么用 Gin 而不是 net/http 或 echo
因为照片墙接口需要高频处理图片元数据（尺寸、格式、EXIF）、支持并发缩略图生成，还要快速响应前端分页请求。Gin 的路由性能和中间件机制比原生 net/http 更省事，而相比 echo，它的 Context 对文件上传、JSON 绑定、路径参数的封装更稳定——尤其在处理 multipart/form-data 上传多张图片时，c.FormFile() 不会像某些框架那样丢帧或阻塞。
GET /api/photos 分页接口怎么避免内存爆掉
直接 SELECT * 加 LIMIT OFFSET 在照片量过万后会变慢，且 Gin 默认把整个结果集加载进内存再序列化。必须用游标分页 + 预加载关键字段：
- 用
created_at和id双字段做游标，避免OFFSET跳跃开销 - 只查
id, filename, width, height, uploaded_at，不查原始二进制或大 EXIF blob - 在数据库层用
WHERE created_at - 返回时补上
next_cursor字段，值为最后一条记录的created_at和id拼接字符串（如"1712345678.123|999"）
缩略图自适应生成该用 golang.org/x/image 还是 github.com/disintegration/imaging
选后者。前者纯 Go 实现，但 JPEG 解码慢、不支持 WebP、缩放算法只有双线性；imaging 底层调用 libjpeg-turbo（编译时需 CGO_ENABLED=1），实测 2000×3000 图片生成 320px 宽缩略图快 3.2 倍，且自带 imaging.Fill 和 imaging.Resize 两种裁剪模式，适配响应式画廊的“居中裁切”需求：
thumb := imaging.Resize(img, 320, 0, imaging.Lanczos)
// 或保持宽高比并填充背景
thumb = imaging.Fill(img, 320, 240, imaging.Center, imaging.Color{240, 240, 240, 255})
注意：别在 HTTP handler 里实时生成缩略图——先用 os.Stat 检查 ./thumbnails/{hash}.jpg 是否存在，不存在再生成并 os.WriteFile 持久化。
前端请求 /api/photos/123 返回 404，但数据库里明明有这条记录
常见三个原因：
- 路由定义写成
router.GET("/api/photos/:id", handler)，但实际请求带了后缀，比如/api/photos/123.jpg—— Gin 默认不匹配，得加通配符：router.GET("/api/photos/:id.*", handler) -
id是 UUID 字符串，但数据库字段类型是BIGINT，Gin 的c.Param("id")拿到字符串后没转类型就直接查，导致查不到 - 图片文件被删了，但数据库记录还在，handler 里做了
os.Stat(filepath)校验却没返回 404，而是 panic 或静默跳过
建议所有资源型 handler 开头统一加校验：
id := c.Param("id")
photo, err := db.GetPhotoByID(id)
if err != nil || !photo.ExistsOnDisk() {
c.JSON(404, gin.H{"error": "photo not found"})
return
}
真实部署时，缩略图路径、原始图路径、数据库 ID 三者一致性最容易被忽略——改一个不改另外两个，就会反复出现 404。
