本文目录
- 一、创建帖子
- Routers
- Controller
- Logic/service
- Dao
- 二、查询帖子接口
- 三、分页查询展示
一、创建帖子
Routers
创建帖子的接口需要经过JWT认证才能访问，相关JWT内容在昨天的博客中已经回顾过了。接下来继续往下看。
Controller
Controller层的代码如下，仍然是三步走。
首先获取参数然后校验、然后转发请求，最后返回。
创建一个Post帖子的实体属性。
这里有一个点可以注意一下：内存对齐概念 字段类型相同的对齐 缩小变量所占内存大小。
一个 uint64 类型的变量必须存储在 8 字节对齐的地址上，一个 int32 类型的变量必须存储在 4 字节对齐的地址上。
内存对齐的目的是为了提高内存访问的效率。现代 CPU 在访问对齐的内存时速度更快，而访问未对齐的内存可能会导致额外的性能开销。
为了优化内存使用，可以将相同类型的字段放在一起，这样可以减少内存对齐带来的“填充”（padding）。填充是编译器为了满足内存对齐要求而插入的空白字节。
在代码中我们通过昨天JWT中间件封装好的方法把UserID先存到上下文context里边，然后方便后续进行别的操作的时候获取。
在 Gin 的中间件或处理函数中，开发者可以通过 gin.Context 的 Set 方法将数据存储到上下文中，后续的处理函数可以通过 Get 方法从上下文中获取这些数据。这种机制使得在请求的生命周期内，数据可以在不同的处理函数之间传递。
在 Gin 框架中，每个 HTTP 请求都会被封装在一个 gin.Context 对象中。这个对象不仅包含了请求和响应的相关信息，还提供了一个键值存储（map），用于存储请求相关的数据。这种机制允许开发者在中间件或处理函数中存储和传递数据。
这样我们就可以通过Get函数来获取对应的UserID了。
_userID 是从上下文中获取的值，其类型为 interface{}。通过类型断言 _userID.(uint64)，尝试将 _userID 转换为 uint64 类型。
这里是因为 Gin 的上下文（gin.Context）内部使用的是一个 map[string]interface{} 来存储键值对，因此获取到的值的类型是 interface{}。
Logic/service
先根据雪花算法生成帖子ID，然后创建帖子存到数据库。
这里还需要把帖子信息存储到redis中，调用了redis.CreatePost()方法进行处理。后边我们再详细讲解Redis相关操作。
Dao
然后执行sql语句把数据插入到数据库中即可。
二、查询帖子接口
查询帖子的接口这边就过的快一点，因为也是一样的流程了。
在Controller层中，可以对接口查询的数据进行数据拼接。
这里就是正常根据帖子id进行查询。
这里我们封装了一个结构体，把帖子的相关信息都封装了进去。
三、分页查询展示
帖子可能会比较多，所以这里可以通过分页功能来展示。
首先我们封装了一个名为getPageInfo的函数，用来获取分页参数。
从 HTTP 请求的查询参数中获取分页信息，包括当前页码（page）和每页显示的数据条数（size）。通过 Gin 框架的 c.Query 方法从请求的 URL 中提取 page 和 size 参数，并将它们从字符串转换为整数。如果转换失败或参数缺失，代码会提供默认值：page 默认为 1，size 默认为 10。最终返回解析后的页码和每页数据条数，以便在后续的分页逻辑中使用。
然后在下面进行for循环，不断拼接接口数据，然后就可以返回了。
然后再dao层进行mysql语句的执行。其中DESC 是 SQL 中的一个关键字，用于指定查询结果的排序顺序。它表示按照某一列的值降序排列（从大到小）。
LIMIT 是 SQL 中的一个子句，用于限制查询结果的数量。它通常用于分页查询，以避免一次性返回过多数据。在查询中：第一个参数：offset，表示跳过前面的记录数。第二个参数：limit，表示返回的最大记录数。
比如：(page-1)*size：计算偏移量（offset），表示跳过前面的记录数。例如，如果 page=2，size=10，则偏移量为 (2-1)*10 = 10，表示跳过前 10 条记录。size：表示每页返回的记录数。
