7.4 KiB
用户端（前端：Web/App/小程序）需要的功能规划
前端技术栈使用 uniapp ，需要对 h5、小程序、app 进行支持
前端的目标是让用户“快速发现地点 → 看懂怎么去怎么拍 → 愿意贡献内容 → 形成互动”。建议把用户端拆成 6 个页面域：发现、地点、创作、互动、约拍、我的。
阶段 1（MVP 必须有）
- 登录注册：手机号/邮箱/第三方（可后置），基本资料（昵称、头像、城市、身份：coser/摄影/都可）
- 地图发现：地图点位展示、同城切换、附近/范围检索、地点列表与地图联动
- 地点详情：场景描述、交通方式、最佳拍摄时间建议、难走路径说明、示例图片/作品、收藏按钮
- 上传地点：表单（标题、城市、坐标、描述、交通、时间建议、路线困难说明）+ 上传示例图；提交后提示“待审核”
- 我的：我的收藏、我上传的地点（审核状态：待审/通过/驳回原因）、积分概览（先只显示即可）
阶段 2（社区增强）
- 评论与回复：评论列表、回复、@、评论举报
- 评分：1~5 星 + 可选短评、展示平均分/评分数
- 标签筛选：按标签筛地点、热门标签
- 搜索：关键词（地点名/描述/标签）
阶段 3（约拍）
- 约拍广场：发布约拍单、筛选（城市/时间/风格/预算/互免）
- 约拍详情：报名、接受/拒绝、状态（开放/匹配/结束）
- 站内沟通：会话列表、消息、拉黑/举报（可选但通常需要）
阶段 4（活动）
- 活动列表与详情：活动发布、报名、通知、活动相册（作品沉淀回地点）
阶段 5（商业化）
- 商业标识：推广位/商家地点清晰标注
- 会员中心：权益展示、购买/续费、发票（如需要）
后端（服务端）需要的功能规划
后端的目标是“统一数据与规则”：地图检索、UGC审核、积分、互动、约拍/活动状态机、统计与风控。建议一开始用单体服务 + 模块化代码结构，以后按流量再拆。
基础能力（无论哪个阶段都要有）
- 鉴权与权限：JWT/Session、角色（user/admin/moderator）、接口权限控制
- 地理能力：坐标存储、附近/范围查询、同城筛选、排序（热门/最近/评分/距离）
- 文件与图片：上传签名、回调入库、图片元信息、缩略图、鉴黄/鉴政（可接第三方）
- 内容安全与风控：频率限制、防刷、敏感词、黑名单、设备/账号风控（起步先做最基本）
- 审核体系：所有UGC都有 audit_status（pending/approved/rejected）与驳回原因
- 通用能力：日志、审计日志、监控、备份、任务队列（生成缩略图/统计汇总）
阶段 1（MVP 的核心 API）
- 用户：注册登录、资料、城市
- 地点：创建/编辑/删除（软删）、列表、详情、地图点位、附近查询
- 地点图片：上传、设封面、删除
- 收藏：收藏/取消收藏、我的收藏列表
- 积分：上传地点审核通过后发放积分（用积分流水 point_ledger）
阶段 2（社区增强 API）
- 评论：发评论/回复、评论列表、删除、举报
- 评分：评分写入/更新、地点评分聚合（avg/count 缓存）
- 标签：标签管理（用户可选/管理员维护）、地点打标签
- 点赞：地点/评论/图片点赞（可选）
阶段 3（约拍 API）
- 约拍单：发布、编辑、关闭、列表筛选、详情
- 报名/邀请：报名、接受/拒绝、撤回、状态机
- 私信：会话、消息、已读、拉黑（如做）
阶段 4（活动 API）
- 活动：发布、报名、取消、通知、活动相册
- 活动与地点关联：活动绑定集合地点、活动产出作品回流地点
阶段 5（商业化 API）
- 推广：投放创建、排期、展示策略、素材
- 统计：曝光/点击/收藏转化日统计
- 会员：权益校验、购买、到期、限制策略（上传额度/置顶次数等）
管理端（后台/运营端）需要的功能规划
管理端的目标是“保证内容质量 + 提升运营效率 + 可追溯”。后台一定要有“列表处理效率”，否则审核会拖垮你。
阶段 1（MVP 必须有）
- 登录与权限：管理员/审核员角色
- 地点审核：待审列表、详情预览（含地图位置与图片）、通过/驳回（填写原因）、下架/恢复
- 地点管理：编辑纠错（坐标、城市、描述）、合并重复地点（可后置）
- 图片审核：图片待审、批量通过/驳回
- 用户管理：用户列表、封禁/解封、查看用户上传历史
- 操作日志：谁在什么时候做了什么（审计日志）
阶段 2（社区治理）
- 评论审核：待审/举报队列、批量处理
- 举报中心：按优先级处理（地点/评论/图片/用户），处理结论记录
- 标签管理：标签新增、合并、禁用、分类维护
- 风控面板：高频上传/刷分/异常账号提示（起步可以非常简单）
阶段 3（约拍/活动运营）
- 约拍管理：违规约拍单下架、用户投诉处理、黑名单
- 活动管理：活动审核（如需要）、报名数据导出、群发通知（站内/短信可选）
阶段 5（商业化运营）
- 推广位管理：排期、素材审核、定价策略
- 报表：曝光/点击/转化、同城/标签维度分析、ROI
- 商家/合作方管理：资质、合同/发票信息（如果走到这一步）
技术栈要求
下面是仅技术栈规定
总体形态
- 架构：前后端分离
- 用户端：uni-app（优先小程序 + H5，后续可打包 App）
- 服务端：Python + FastAPI（REST API 为主）
- 管理端：基于 FastAPI 的管理后台（可用现成 Admin 组件快速生成）
前端（uni-app）技术栈规定
- 框架：uni-app（建议 Vue3）
- UI 组件库：固定选一套（如 uView / thorui / NutUI），避免混用
- 状态管理：Pinia（Vue3）或 uni-app 官方推荐方案（二选一）
- 网络请求：统一封装（token 自动携带、错误码统一处理）
- 地图能力：统一选定一个地图服务（国内优先高德/腾讯），多端适配按同一供应商方案走
- 图片上传：使用对象存储直传（前端上传、后端签名/回调）
后端（FastAPI）技术栈规定
-
Web 框架：FastAPI
-
ASGI 服务器：Uvicorn（生产可配 Gunicorn + UvicornWorker）
-
ORM：SQLAlchemy 2.x（或 SQLModel，二选一且全项目统一）
-
数据库迁移：Alembic
-
数据库：PostgreSQL
- 强烈建议：PostGIS（地理位置检索/附近查询/范围查询）
-
缓存与消息：Redis
- 用途：限流、验证码、缓存、任务队列 broker（如需）
-
异步任务（可选但建议预留）：Celery（broker 用 Redis）
-
对象存储：S3 兼容（MinIO/OSS/COS 任一，统一用 S3 兼容 SDK 方案）
-
鉴权：JWT（access + refresh）或 OAuth2 password flow（统一规范）
-
数据校验：Pydantic（FastAPI 自带）
-
日志：标准 logging + 结构化日志（JSON）
-
错误监控：Sentry（或同类错误上报方案）
管理端技术栈规定（基于 FastAPI）
- 管理后台：sqladmin / fastapi-admin（二选一且统一）
- 权限：RBAC（至少 admin / moderator / user）
- 审计：管理操作写入审计日志表（谁、何时、对什么做了什么）