这是我参与「第五届青训营」伴学笔记创作活动的第15天。

前言

前文介绍了投稿接口的大致写法，这里补充几点。
在打开一个文件流之后，我们需要关闭这个函数，我们可以用defer关键字先进后出的特性来构造一个匿名函数，如：

defer func(opened multipart.File) {
   err := opened.Close()
   //错误处理
      return
   }
}(opened)

当整个投稿函数结束之前的最后一步，这个函数才会执行，达到关闭文件流的效果。

然后，我们在客户端测试时发现，稍微过大一点的视频文件都传不上来，解决办法也很简单，我们需要在注册服务器端口的时候设置最大请求体大小：

h := server.Default(server.WithHostPorts(Service.Port), server.WithMaxRequestBodySize(2000*1024*1024))

这样就可以接收包含大文件body请求，括号内的参数可以自行调整。

数据表结构

在list接口、视频流接口等地方的返回响应我们可以看到一个非常套娃的结构体：

type List struct {
   StatusCode int64      `json:"status_code"` // 状态码，0-成功，其他值-失败
   StatusMsg  *string    `json:"status_msg"`  // 返回状态描述
   VideoList  []RspVideo `json:"video_list"`  // 用户发布的视频列表
}
type Video struct {
   Author        User `json:"author"`         // 视频作者信息
  //....
}

type User struct {
  //....
}

User属于Video，然后Video属于List。
于此我们必须思考一下我们应当创建的数据表的结构：

1. 两张表
2. 两张表有关联

我们需要一个User表，以及一个Video表，以平常经验来判断，一个用户可以投稿多个视频，明显我们需要将Userid插入Video表中，来达到属于的效果。我们可以使用Userid在Video表中查到哪些视频为这个Userid对应的用户投的稿。
当然，你也可以使用外键约束，这里不多赘述。
此外，访问的Model并不一定适合直接拿来建表，或者说数据表的Model本就应该和访问的Model分开使用，比如响应需要的UserModel不应该包含用户的token、password等字段。