16. Instagram/小红书 图片社交

V1 — 1个用户：纯前端图片展示

场景

你想做一个个人图片墙，展示旅行照片，支持瀑布流布局和点赞收藏。

你要解决什么

用纯前端实现图片瀑布流展示、点赞功能，数据存localStorage。

给AI的Prompt

帮我用纯HTML+CSS+JavaScript实现一个图片社交页面：

1. 图片数据：
   - 硬编码10-15张图片（用picsum.photos随机图片URL）
   - 每张图片：id, url, caption, likes, liked, saved, created_at
2. 瀑布流布局：
   - 纯CSS实现（column-count或CSS Grid）
   - 响应式：手机1列，平板2列，桌面3列
   - 图片懒加载（Intersection Observer）
3. 交互功能：
   - 双击图片点赞（❤️动画浮出）
   - 点击心形图标切换点赞状态
   - 点击书签图标收藏/取消收藏
   - 点赞数实时更新
4. 图片详情弹窗：
   - 点击图片打开大图弹窗
   - 显示图片、描述、点赞数
   - 弹窗内可左右切换图片
5. 数据持久化：所有点赞和收藏状态存localStorage
6. 收藏页面：筛选显示已收藏的图片

不用框架，纯原生实现。重点关注瀑布流布局和双击点赞动画。

验证清单

• 瀑布流布局正常，不同屏幕宽度自适应
• 双击点赞有动画效果
• 点赞和收藏状态刷新后保留
• 图片懒加载生效
• 详情弹窗可左右切换

你学到了什么

• 瀑布流布局的CSS实现方案 → Module: CSS布局
• Intersection Observer实现懒加载 → Module: 前端性能
• localStorage数据持久化 → Module: 浏览器存储

---

V2 — 10个用户：图片上传和社交

场景

从个人图片墙变成小型社交应用，10个朋友互相分享照片。需要后端支持图片上传、用户关注和时间线。

你要解决什么

Go后端实现图片上传存储、用户关注关系、简单时间线。

给AI的Prompt

帮我用Go+Gin+SQLite实现图片社交后端：

1. 数据模型：
   - users: id, username, avatar_url, bio
   - posts: id, user_id, image_path, caption, created_at
   - likes: user_id, post_id, created_at (联合主键)
   - follows: follower_id, following_id, created_at (联合主键)
2. 图片上传：
   - POST /api/posts — multipart/form-data上传图片+描述
   - 图片存本地 data/uploads/ 目录
   - 限制：最大5MB，只允许jpg/png/webp
   - 返回图片访问URL
3. 社交功能API：
   - POST /api/users/:id/follow — 关注
   - DELETE /api/users/:id/follow — 取关
   - GET /api/users/:id/followers — 粉丝列表
   - GET /api/users/:id/following — 关注列表
4. 时间线：
   - GET /api/feed — 返回所关注用户的帖子（按时间倒序）
   - SQL: SELECT posts.* FROM posts JOIN follows ON ... ORDER BY created_at DESC
   - 分页：cursor-based（基于created_at）
5. 互动：
   - POST /api/posts/:id/like — 点赞/取消点赞（toggle）
   - GET /api/posts/:id — 帖子详情含点赞数和是否已赞
6. 静态文件服务：Gin提供 /uploads/ 路径访问上传的图片

注意：SQLite单文件，不需要额外服务。

验证清单

• 图片上传成功且可通过URL访问
• 超过5MB的文件被拒绝
• 关注后feed中出现对方的帖子
• 点赞toggle正确工作
• cursor分页正确翻页

你学到了什么

• 文件上传处理和校验 → Module: 文件上传
• 关注关系的数据建模（多对多） → Module: 关系型数据建模
• Cursor-based分页 vs Offset分页 → Module: 分页策略

---

V3 — 100个用户：对象存储和图片处理

场景

用户增多，本地磁盘存图片不可靠。上传的原图太大加载慢，需要自动生成缩略图。

你要解决什么

图片存对象存储（MinIO模拟S3），上传时自动生成多尺寸缩略图。

给AI的Prompt

在V2基础上引入对象存储和图片处理：

1. 双写存储：
   - PostgreSQL存元数据（帖子信息、URL引用）
   - MinIO（S3兼容）存图片文件
   - posts表增加字段：original_url, thumbnail_url, medium_url
2. 图片处理流水线（上传时）：
   - 原图：保持原始尺寸，存 originals/{id}.jpg
   - 中等：宽度800px等比缩放，存 medium/{id}.jpg
   - 缩略图：300x300中心裁剪，存 thumbnails/{id}.jpg
   - 用Go imaging库处理
3. 图片优化：
   - 自动EXIF方向修正
   - 剥离EXIF元数据（隐私保护）
   - 质量压缩到80%
4. 前端适配：
   - 列表页用thumbnail_url（省流量）
   - 详情页用medium_url
   - 点击查看原图用original_url
5. 迁移脚本：
   - 把V2本地存储的图片迁移到MinIO
   - 批量生成缩略图

提供docker-compose.yml包含PostgreSQL和MinIO。

验证清单

• 上传图片后MinIO中生成三种尺寸
• 列表页加载缩略图而非原图
• EXIF方向修正正确（竖拍照片不会横过来）
• EXIF元数据被清除
• 迁移脚本正确把旧图片搬到MinIO

你学到了什么

• 对象存储（S3/MinIO）的使用 → Module: 对象存储
• 图片处理流水线设计 → Module: 图片处理
• 元数据和文件分离存储 → Module: 存储架构
• EXIF和隐私保护 → Module: 数据安全

---

V4 — 1000个用户：Feed优化

场景

1000人关注关系复杂，每次刷新Feed都要JOIN大量数据，越来越慢。热门帖子点赞数频繁更新导致DB压力大。

你要解决什么

Redis缓存Feed时间线，推模式分发，点赞计数器优化。

给AI的Prompt

在V3基础上优化Feed性能：

1. Feed推模式：
   - 用户发帖时，异步把帖子ID推送到所有粉丝的Feed列表
   - Redis List存储每个用户的Feed：feed:{user_id} → [post_id, ...]
   - 保留最近500条
   - 异步推送用goroutine + channel
2. Feed读取优化：
   - GET /api/feed 从Redis List读取post_id列表
   - 批量查询帖子详情（Redis缓存 + DB兜底）
   - 帖子详情缓存：post:{id} → JSON，TTL 10分钟
3. 点赞计数器：
   - Redis INCR/DECR 实时计数：post_likes:{post_id}
   - 每5分钟异步回写到PostgreSQL
   - 读取时优先从Redis获取
4. 热门帖子：
   - 按最近24小时点赞数排序
   - Redis Sorted Set：hot_posts → {post_id: score}
   - score = 点赞数 * 时间衰减因子
   - GET /api/explore/hot — 热门帖子列表
5. 取关处理：
   - 取关后从Feed List中移除该用户的帖子
   - 异步清理，不阻塞取关操作

提供docker-compose.yml包含PostgreSQL + Redis + MinIO。

验证清单

• 发帖后粉丝的Feed中出现新帖子
• Feed读取速度<50ms（Redis缓存命中时）
• 点赞数Redis和DB最终一致
• 热门帖子按热度排序
• 取关后Feed中旧帖子被清理

你学到了什么

• Feed推模式（Fan-out on write） → Module: Feed系统设计
• Redis计数器和异步回写 → Module: 缓存一致性
• 热度算法和时间衰减 → Module: 排序算法
• 异步处理解耦 → Module: 异步架构

---

V5 — 1万用户：搜索和发现

场景

用户想通过标签搜索感兴趣的内容，想发现新的有趣账号。简单的SQL LIKE搜索已经扛不住了。

你要解决什么

引入Elasticsearch实现标签搜索和内容发现，构建explore发现页。

给AI的Prompt

在V4基础上实现搜索和发现功能：

1. 标签系统：
   - tags表：id, name, post_count
   - post_tags表：post_id, tag_id
   - 发帖时从caption中提取#标签
   - 热门标签：按post_count排序
2. Elasticsearch索引：
   - posts索引：id, caption, tags, user_id, username, likes_count, created_at
   - 发帖/更新时同步到ES（异步）
   - 支持中文分词（ik_max_word）
3. 搜索API：
   - GET /api/search/posts?q=xxx — 全文搜索帖子
   - GET /api/search/tags?q=xxx — 搜索标签（自动补全）
   - GET /api/search/users?q=xxx — 搜索用户名
   - 搜索结果高亮匹配词
4. Explore发现页：
   - GET /api/explore — 推荐内容
   - 推荐策略（简单版）：
     - 你关注的人点赞的帖子
     - 与你关注相同标签的热门帖子
     - 新用户热门内容兜底
5. 标签页面：
   - GET /api/tags/:name/posts — 某标签下的帖子列表
   - 按热度或时间排序
6. 搜索建议：
   - 用ES completion suggester实现
   - 输入时实时返回建议

提供docker-compose.yml增加Elasticsearch。

验证清单

• 中文搜索能正确找到帖子
• 标签自动补全<100ms响应
• Explore页推荐内容个性化
• 搜索结果高亮关键词
• 新帖发布后搜索可见（<5秒延迟）

你学到了什么

• Elasticsearch全文搜索和中文分词 → Module: 搜索引擎
• 推荐系统的冷启动和简单策略 → Module: 推荐系统入门
• 标签系统设计 → Module: 分类和标签
• 搜索建议（Completion Suggester） → Module: 自动补全

---

V6 — 10万+用户：推荐系统和商业化

场景

用户量级跳升，需要个性化推荐留住用户。同时需要广告系统实现商业化变现。

你要解决什么

构建协同过滤推荐系统、AI图片标签理解、广告投放引擎。

给AI的Prompt

设计并实现推荐和商业化系统：

1. 协同过滤推荐：
   - 基于用户的协同过滤：找到相似用户，推荐他们喜欢的内容
   - 相似度计算：Jaccard相似度（基于共同点赞的帖子）
   - 离线计算：每天凌晨批量计算用户相似度矩阵
   - 在线推荐：从相似用户的行为中选取候选 → 排序 → 去重已看
2. 内容理解（预留AI接口）：
   - 图片标签提取接口：POST /api/internal/analyze-image
   - 预留调用外部Vision API的位置（当前用mock返回随机标签）
   - 标签存入posts索引，增强搜索和推荐
3. 推荐混排：
   - Explore页混合多个来源：
     - 协同过滤推荐（40%）
     - 基于标签的内容推荐（30%）
     - 热门内容（20%）
     - 新用户冷启动兜底（10%）
   - 去重+打散（连续不超过2条同一作者）
4. 广告系统：
   - ads表：id, advertiser_id, image_url, target_url, budget, cpc, targeting
   - 广告投放逻辑：在Feed第5、15、25位插入广告
   - 简单定向：按用户标签兴趣匹配
   - 计费：CPC（点击计费），预算消耗完下线
5. 数据埋点：
   - 记录：曝光、点击、停留时长、点赞、收藏
   - 用于训练推荐模型和广告效果评估
6. 效果评估：
   - A/B测试：不同推荐策略对比
   - 核心指标：CTR点击率、停留时长、次日留存

重点实现协同过滤算法和推荐混排逻辑。

验证清单

• 相似用户计算合理（共同点赞越多相似度越高）
• 推荐结果个性化（不同用户看到不同内容）
• 广告按预期位置插入Feed
• 广告预算消耗完后停止展示
• 数据埋点正确记录用户行为

你学到了什么

• 协同过滤算法（User-based CF） → Module: 推荐算法
• 推荐系统的召回-排序-混排流程 → Module: 推荐系统架构
• 广告系统基础（CPC、定向、预算控制） → Module: 广告系统
• A/B测试和效果评估 → Module: 数据驱动