简介：一套基于 Go 语言开发的校园论坛微信小程序完整源码，面向有基本后端基础、希望搭建校园交流社区或学习 Go 后端与小程序接口设计的开发者。项目按 service、router、models、apis 等模块分层，覆盖用户、帖子、评论、管理等核心业务，并集成 JWT 鉴权、雪花 ID、日志与参数校验、Swagger 接口文档、MySQL/Redis 数据层和 Dockerfile 部署配置，能帮助读者理解 Go 并发模型在真实社区场景中的应用。微信小程序免下载安装、用完即走的特性，配合 Go 语言的高并发与静态编译优势，使得这套源码很适合作为课程设计、毕业设计或项目实战练手。压缩包共 56 个文件，以 36 个 Go 源文件为主，辅以 XML/YAML 配置、Makefile、Dockerfile、README 等文件，包体约 29.19MB，目录结构清晰，便于按模块阅读和二次开发。已有 300 人浏览学习，对想学习小程序后端接口开发、快速搭建校园论坛的开发者，是一份完整的参考实现。
1. 校园论坛微信小程序：为什么我要用Go重写这套后端
某高校信息中心想给在校生做校园论坛小程序，最初按传统方案写后端，结果早高峰几百人同时刷帖，接口响应直接飙红。换到这套基于Go语言开发的校园论坛微信小程序设计源码后，后端编译成一个二进制文件扔服务器就能跑，并发压力轻松兜住。项目把微信小程序前端、Go后端、MySQL、Redis、JWT鉴权、Swagger文档打包在一起，从页面到接口都有完整源码。适合想用真实项目练手的Go开发者，也适合高校数字校园项目里需要快速落地论坛场景的团队。下面从架构、目录、核心代码到部署改造，完整拆一遍。
2. 技术选型与整体架构：Go的并发模型如何撑起校园论坛
2.1 为什么是Go加微信小程序：轻客户端与强后端的分工
校园论坛这类业务有个特点：读多写少，早高峰集中，晚自习后又有小高峰。用户刷帖子列表、看详情、翻评论，这些都是高频率的读请求；发帖和回帖虽然写入不多，但一旦活动期间集中发文，对事务和一致性也有要求。Go语言在这种场景下的优势非常直接：goroutine 让每个请求可以以极低的内存开销并发处理，配合 net/http 或 gin 这类高性能框架，单机就能扛住上千并发连接。
相比 Java 系需要起一个重量级容器，Go 编译产物就是单个可执行文件，部署时拷贝、给权限、起进程三步搞定，这对高校机房的 Linux 服务器特别友好。项目里把微信小程序当作纯粹的前端壳，所有页面数据都通过 HTTP 接口从 Go 后端获取，前端不持有任何业务状态，天然适合“轻客户端强后端”的分工。小程序端只要负责渲染、交互和用户登录态的存储，业务逻辑、权限控制、数据校验全部收敛到后端。
2.2 分层设计：apis、service、models、dao 各司其职
从项目目录可以清楚看到这套代码沿用了常见的 Go Web 分层模式，四个模块各自独立成组：
- apis 层：接收 HTTP 请求，解析参数，调用 service 层，返回统一响应
- service 层：处理业务逻辑，比如密码校验、发帖状态判断、评论计数更新
- models 层：定义数据表结构和字段标签，对应 MySQL 中的表
- dao 层（隐含在 service 内部）：封装所有 SQL 操作，对 service 层屏蔽数据库细节
拿 user 模块举例，apis/user/router 只负责把 URL 绑定到 handler，handler 解析 JSON 请求体后交给 UserService 的 Login 方法，Login 内部再调用 dao 层查库。这样改数据库查询不影响接口签名，换表结构不碰路由，多个模块之间的代码不会纠缠在一起。项目里 user、post、comment、admin 四个子模块都遵循同一套结构，掌握了其中一个，其余三个基本可以触类旁通。
单独说一下 admin 模块。admin 拥有用户管理、内容审核、置顶帖等敏感操作，所以它没有直接复用 user 的 service，而是拆出了一条独立链路，从路由到 models 都是单独一套。这在多角色系统里是合理的设计选择：管理端和用户端未来权限模型大概率会分叉，从一开始就分目录，避免后期把 admin 逻辑塞进 user 模块再拆出来的返工成本。
2.3 存储设计：MySQL扛持久化、Redis顶热点
项目里 database 目录下同时出现了 mysql.go 和 redis.go，说明这套论坛从设计之初就没打算用单库搞定所有数据，而是各司其职。
MySQL 负责持久化主数据：用户表、帖子表、评论表、管理员表。这些表一旦写入基本不会丢，按业务主键索引查询，支撑论坛的常规读写。Redis 则处理两类场景，一类是热点缓存，比如首页热帖列表、帖子详情，缓存命中时直接从内存返回，不给 MySQL 加压力；另一类是临时态数据，比如用户登录态的 token 黑名单、验证码的短期存储、接口频控计数。
我在跑这套代码时特别注意了一下 redis.go 里的 key 命名设计，它基本遵循“模块:对象:标识”的格式，比如 post:detail:{id}、post:list:hot。这种命名方式的好处是排查问题时用 redis-cli keys 扫一遍就能看出业务分布，也方便按前缀批量清理缓存。如果你打算二次开发，建议保持这个风格，别把 key 写得随心所欲，不然后面缓存穿透和脏数据会变成玄学问题。
3. 目录地图与基础组件：55个文件里最值得先看的6个pkg
3.1 从目录树认识项目：36个Go文件如何分布
整个项目压缩包解开后，根部有几个重点文件：main.go 是启动入口，go.mod 管依赖版本，Makefile 封装了常用命令，.air.conf 是开发热重载配置。先看目录结构，心里有张地图：
CampusForum/ ├── main.go # 入口：初始化配置、数据库、路由 ├── conf/ │ └── config.yaml # 端口、MySQL、Redis、JWT密钥配置 ├── database/ │ ├── mysql.go # MySQL连接池初始化 │ └── redis.go # Redis客户端初始化 ├── router/ │ └── router.go # 全局路由注册与中间件装配 ├── apis/ │ ├── user/ # 用户模块 │ │ ├── router/ # 路由定义 │ │ ├── service/ # 业务逻辑 │ │ └── models/ # 数据模型 │ ├── post/ # 帖子模块 │ ├── comment/ # 评论模块 │ └── admin/ # 管理端模块 ├── pkg/ │ ├── jwt/ # token生成与解析 │ ├── snowflake/ # 分布式ID生成 │ ├── logger/ # 日志封装 │ ├── response/ # 统一返回结构 │ └── validator/ # 参数校验工具 ├── docs/ # swagger文档 ├── Dockerfile # 容器化部署 ├── Makefile # 构建命令 └── .air.conf # 热重载配置36个Go源文件并不算多，拆到每个模块更薄：user 和 post 是业务大头，各自有完整的 router、service、models 文件组；comment 相对轻量，依赖 post 的上下文；admin 独立成组，但底层复用了 pkg 里的 JWT、response 和 snowflake。pkg 包里那6个文件是整个项目的工具箱，后面逐个拆。
3.2 路由注册与中间件：请求从header到handler的完整路径
router.go 负责把全局中间件和四个业务模块的路由挂到同一个引擎上。从代码风格看，它使用了 gin 框架的路由组机制，一组一挂，模块间互不干扰。核心代码大致这样：
func SetupRouter() *gin.Engine { r := gin.Default() // 跨域中间件，小程序请求需要带token header r.Use(middleware.Cors()) // 公开接口组：登录、注册、帖子列表 api := r.Group("/api/v1") { user.NewRouter(api.Group("/user")) post.NewRouter(api.Group("/post")) comment.NewRouter(api.Group("/comment")) admin.NewRouter(api.Group("/admin")) } return r }这段代码的关键在于分组嵌套。api.Group("/user") 返回的是一个独立路由组，user.NewRouter 在组内继续绑定 POST /login、POST /register 这些子路径，最终完整路径就是 /api/v1/user/login。中间件通过 r.Use 作用到整个引擎，CORS 处理了跨域头，让小程序端能正常携带 Authorization header。
实际跑起来你会发现，admin 路由组额外挂了一层 JWT 校验中间件，而 user 的登录注册接口是放开的。这就是路由注册层面的权限隔离：先按路径分组，再按组挂中间件，比在每个 handler 里手写鉴权判断干净得多。
3.3 JWT与Snowflake：两个小工具分别解决什么
先看雪花算法。论坛发帖、评论、用户表的主键不适合用自增ID，因为一旦做分库分表或者数据迁移，自增ID会撞车。pkg/snowflake 基于时间戳、机器ID和序列号生成64位唯一ID，单机每秒能生成几十万个不重复ID。项目里初始化时会传入一个workerID，不同实例配不同ID，就能保证集群环境不重复：
var node *snowflake.Node func Init(workerID int64) error { n, err := snowflake.NewNode(workerID) if err != nil { return err } node = n return nil } func NextID() int64 { return node.Generate().Int64() }调用方式就是业务代码里一句 post.ID = snowflake.NextID()。雪花ID的好处除了全局唯一，还能从数值中读出生成时间，排查数据问题时不用查 create_time 字段就能约摸判断写入顺序。注意 workerID 不要超过节点上限，多实例部署时配置错会直接 panic。
JWT 模块更直接。用户登录成功后，后端签发一个带过期时间的 token，小程序端存进 storage，后续每个请求在 header 里带上。pkg/jwt 里封装了 GenerateToken 和 ParseToken 两个函数，登录接口拿到用户ID和用户名后签发，受保护的接口用中间件解析：
func JWTAuth() gin.HandlerFunc { return func(c *gin.Context) { token := c.GetHeader("Authorization") if token == "" { response.Fail(c, response.CodeUnauthorized, "缺少token") c.Abort() return } claims, err := jwt.ParseToken(token) if err != nil { response.Fail(c, response.CodeUnauthorized, "登录状态已过期") c.Abort() return } c.Set("userID", claims.UserID) c.Next() } }关键在 c.Set 和 c.Next 这两行。c.Set 把解析出的用户ID写进请求上下文，后续 handler 里通过 c.GetInt64("userID") 就能拿到当前用户，不用重复解析 token。c.Next 是放行后续处理链，如果 token 非法则 c.Abort 立刻截断。这里有个很容易踩的小坑：微信小程序请求 header 的 key 默认会被转成小写，服务端 GetHeader 用 "Authorization" 能正确拿到，但有些同学会写成 "authorization"，排查时容易看不出来。
3.4 response与validator：让所有接口说同一种话
pkg/response 做的事情很简单，就是把所有接口的返回格式统一掉。前端不用针对每个接口判断结构，只要看清 code、msg、data 三层就行：
func Success(c *gin.Context, data interface{}) { c.JSON(http.StatusOK, gin.H{ "code": 0, "msg": "success", "data": data, }) } func Fail(c *gin.Context, code int, msg string) { c.JSON(http.StatusOK, gin.H{ "code": code, "msg": msg, "data": nil, }) }这里统一用 HTTP 200 承载业务状态码，而不是让 HTTP 状态码参与业务判断。很多刚上手 Go 后端的开发者习惯用 404、500 来表达业务错误，但小程序端处理起来非常麻烦——网络错误和业务错误混在一起。项目这种设计，HTTP 层只看有没有到服务器，业务层只看 code 值，前后端协作的边界非常清晰。
pkg/validator 则负责把参数校验从 handler 里抽出来。以发帖接口为例，标题为空、正文过长这类校验统一走 validator，handler 里只需要调用一个函数，不通过就直接返回带错误信息的响应。常见做法是给 models 结构体打 binding 标签，gin 框架内置的 validator 会自动完成必填、长度、格式的检查，几个常用标签就够覆盖论坛业务的大部分需求。
4. 核心业务模块拆解：用户、帖子、评论、管理员四条业务链
4.1 用户模块：注册、登录与token签发流程
user 模块是整个论坛的门面，所有操作都建立在登录态之上。注册接口接收小程序端传来的用户名和密码，service 层先确认用户名未被占用，再用 bcrypt 算法把密码哈希后存入 MySQL，绝不允许明文落库。登录接口的逻辑稍微多一点，校验完密码后还要生成 token 并返回给前端：
func (s *UserService) Login(username, password string) (*LoginResponse, error) { var user User if err := s.dao.FindByUsername(username, &user); err != nil { return nil, errors.New("用户不存在") } if !checkPassword(user.PasswordHash, password) { return nil, errors.New("密码错误") } token, err := jwt.GenerateToken(user.ID, user.Username, 7*24*time.Hour) if err != nil { return nil, err } return &LoginResponse{ Token: token, UserID: user.ID, Username: user.Username, }, nil }这段代码里值得注意的有三点。第一，FindByUsername 查询走的是用户名唯一索引，不存在时直接返回错误，不用继续做密码校验，省了一次无畏的哈希比对。第二，checkPassword 比较的是哈希值，而不是明文，即使数据库泄露也不会直接暴露用户密码。第三，token 有效期设为7天，小程序端不需要频繁重新登录，但代价是泄露风险变高，admin 模块的token有效期就会设得更短，这是一种按业务风险做差异化配置的思路。
4.2 帖子模块：发帖、列表与详情接口的缓存取舍
帖子模块是论坛的核心内容源，它的 service 层代码最能体现读写分离的缓存策略。发帖接口除了往 MySQL 写入记录，还要顺手清理 Redis 里的热帖列表缓存；列表接口则先查缓存，没命中才回源数据库：
func (s *PostService) CreatePost(userID int64, req CreatePostRequest) (*Post, error) { post := &Post{ ID: snowflake.NextID(), UserID: userID, Title: req.Title, Content: req.Content, Status: 1, CreatedAt: time.Now(), } if err := s.dao.Create(post); err != nil { return nil, err } // 新帖发布后，热帖列表缓存失效 s.cache.Delete("post:list:hot") return post, nil } func (s *PostService) ListHotPosts(page, size int) ([]*Post, error) { cacheKey := fmt.Sprintf("post:list:hot:%d:%d", page, size) if cached, err := s.cache.Get(cacheKey); err == nil { var posts []*Post json.Unmarshal([]byte(cached), &posts) return posts, nil } posts, err := s.dao.ListByStatus(1, page, size) if err != nil { return nil, err } // 回源后写缓存，过期时间控制5分钟 data, _ := json.Marshal(posts) s.cache.Set(cacheKey, string(data), 5*time.Minute) return posts, nil }发帖接口里删除缓存而不是直接更新缓存，是这套代码里最稳妥的处理方式。因为热帖列表的排序规则可能涉及多个字段，如果只把新帖塞进缓存，排序权重变化反而导致缓存数据和 MySQL 不一致，干脆删掉让下次请求回源重建。列表接口的缓存 key 带上了页码和大小，不同页面的缓存彼此独立，避免翻页时相互覆盖。缓存过期设5分钟，既保证新鲜度，又不会让 MySQL 承受每一条请求的回源压力。
4.3 评论模块：平铺表结构如何支持楼中楼展示
评论模块是论坛里最容易越写越复杂的部分，很多项目一开始就上了一套递归树结构，最后查询性能惨不忍睹。这套源码采用的是平铺表结构，每条评论只记录 post_id、user_id、content 和 parent_id，parent_id 为 0 表示顶层评论，非 0 表示是某条评论的回复。查询时一次性拉出该帖所有评论，在内存里按 parent_id 组装树：
func BuildCommentTree(comments []*Comment) []*CommentNode { nodes := make(map[int64]*CommentNode, len(comments)) for _, c := range comments { nodes[c.ID] = &CommentNode{Comment: c, Children: make([]*CommentNode, 0)} } roots := make([]*CommentNode, 0) for _, n := range nodes { if n.ParentID == 0 { roots = append(roots, n) } else if parent, ok := nodes[n.ParentID]; ok { parent.Children = append(parent.Children, n) } } return roots }这段代码用了一个 map 把所有评论节点暂存起来，然后第二遍遍历时通过 parent_id 找到父节点并挂载到 Children 切片。整个过程时间复杂度是 O(n)，比递归查询的写法高效得多，而且完全在内存中完成，不产生额外的数据库查询。要注意的是，如果 parent_id 指向的评论已被删除，代码里用 ok 判断兜底，放弃挂载这条孤儿评论，避免递归时出现死循环。
ams">对于楼层数特别多的热帖，一次性加载所有评论确实会增大响应体，但微信小程序端以滚动加载为主，一次拉全量评论的体验反而比多级分页好。数据库的索引设计也很直接：post_id 建索引，查询评论时走索引即可，parent_id 只负责组装，不需要单独建索引。
4.4 admin模块：管理端与用户端的权限隔离
admin 目录独立成组，从 router 到 service 都没跟 user 模块混在一起。管理端的操作列表包括审核帖子、删除评论、置顶、封禁用户，这些接口全部挂在 /api/v1/admin 路由组下，并且整组套上了 admin 专用的 JWT 中间件。这个中间件比普通用户中间件多做了一层角色校验：
func AdminAuth() gin.HandlerFunc { return func(c *gin.Context) { token := c.GetHeader("Authorization") claims, err := jwt.ParseToken(token) if err != nil { response.Fail(c, response.CodeUnauthorized, "登录状态已过期") c.Abort() return } // 从用户表/管理员表中确认角色 if claims.Role != "admin" { response.Fail(c, response.CodeForbidden, "无权限访问") c.Abort() return } c.Set("adminID", claims.UserID) c.Next() } }这里的关键是 Role 字段。签发 token 时把角色写进 claims，AdminAuth 中间件只认 role 为 admin 的 token，普通用户 token 即使合法也会被拒绝。这样用户端和管理端的 token 体系完全兼容，但访问边界被中间件硬性隔离，不依赖某个 handler 里手写判断。
做完这一步后，admin 的 service 层操作的是同一批帖子表和评论表，只是行为不同：删除帖子时会同步更新帖子状态字段，而不是物理删除，这样用户端列表接口通过 Status 条件自然过滤掉违规内容，数据库里还能保留审计痕迹。
5. 从零启动到Docker部署：配置、运行与避坑清单
5.1 准备环境：Go、MySQL、Redis一个都不能少
这套源码的运行依赖三个基础环境：Go 1.20 以上版本、MySQL 5.7 或 8.0、Redis 6.x。Go 版本太旧会导致 go.mod 里的依赖解析失败，编译时报一些奇奇怪怪的语法错误，所以第一步先确认 go version。MySQL 建议用 8.0，因为项目里的建表语句和默认字符集大概率按 utf8mb4 配置，8.0 对 utf8mb4 的支持更省心，避免出现 emoji 存不进去的尴尬。
Redis 不需要哨兵或集群，单机模式足够开发调试用。注意 Redis 的密码配置，如果服务器上的 Redis 开了 requirepass，必须在 config.yaml 里填对密码，否则启动时连接 Redis 失败，整个服务直接退出。数据库初始化方面，项目没有内置迁移工具，你需要自己在 MySQL 里执行建表语句，或者根据 models 里的结构体手写 CREATE TABLE。
5.2 启动流程：从config.yaml到main.go的初始化顺序
配置文件 config.yaml 集中在 conf 目录，包含服务端口、MySQL 连接串、Redis 地址、JWT 密钥等关键参数。首次运行时把配置改成你自己的环境，特别是 MySQL 的用户名密码和 Redis 密码。main.go 的初始化顺序非常有代表性，几乎每个 Go Web 项目都是同一套节奏：
func main() { // 1. 读取配置 conf, err := config.Load("conf/config.yaml") if err != nil { log.Fatalf("加载配置失败: %v", err) } // 2. 初始化日志 logger.Init(conf.Logger) // 3. 初始化数据库连接 database.InitMySQL(conf.MySQL) database.InitRedis(conf.Redis) // 4. 初始化雪花算法节点 snowflake.Init(conf.Snowflake.WorkerID) // 5. 注册路由并启动 r := router.SetupRouter() r.Run(conf.Server.Port) }这个顺序是有讲究的。先读配置，后面的所有初始化都要依赖配置内容；日志放前面，这样后续步骤出错时有地方记录；数据库和 Redis 连接是业务依赖，必须全部成功才能继续；最后才启动 HTTP 服务。如果顺序颠倒，比如先启动服务再连数据库，就会出现请求到达时数据库还没准备好的尴尬窗口期。
启动命令也不复杂。项目里提供了 Makefile，直接在项目根目录执行 make run 就能跑起来；如果不想用 make，也可以 go run main.go。开发调试时 .air.conf 里配置了热重载，修改 Go 代码后自动重新编译并重启服务，省去手动 Ctrl+C 再 run 的重复操作。需要生成 swagger 文档的，在 docs 目录下有 swagger.yaml 和 swagger.json，配合 docs.go 可以在线调试接口。
5.3 Docker部署：用Dockerfile把后端打包成镜像
项目自带 Dockerfile，部署生产环境时非常省事。它采用多阶段构建：第一个阶段用 golang 镜像编译出静态二进制，第二阶段用 alpine 作为运行镜像，只拷贝编译产物和配置文件，整个镜像体积控制在几十MB级别。核心步骤：
# 构建阶段 FROM golang:1.20 AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN go build -o campus_forum main.go # 运行阶段 FROM alpine:latest WORKDIR /root/ COPY --from=builder /app/campus_forum . COPY conf/config.yaml ./conf/ EXPOSE 8080 CMD ["./campus_forum"]要注意的是，config.yaml 里如果写的是 localhost 或者 127.0.0.1，容器内是访问不到宿主机 MySQL 的。真实部署时用 docker run 加 -e 参数覆盖配置，或者把 config.yaml 里 MySQL 地址改成 docker-compose 服务名。推荐的做法是准备一份 docker-compose.yaml，把 MySQL、Redis、论坛服务三个容器编排在一起，服务容器通过服务名访问数据库容器，这样网络问题最少。
构建命令分两步：先 docker build -t campus-forum . 构建镜像，再 docker run -p 8080:8080 campus-forum 启动。启动后先用 curl 打一下健康检查接口确认服务活着，再看日志有没有 MySQL、Redis 连接报错。容器里查日志用 docker logs -f 容器ID，定位启动失败基本全靠它了。
5.4 避坑清单：五个高发问题与对应排查方法
问题一：启动报 redis connection error，服务直接退出。原因基本是 Redis 地址写错或密码不对。解决：先 redis-cli ping 验证 Redis 本身可用，再对照 config.yaml 的地址和密码确认，注意密码有特殊字符时要用引号包起来。
问题二：小程序请求一直报跨域。虽然后端写了 CORS 中间件，但微信小程序开发工具里有时候请求的域名是本地 IP 加端口，后端 CORS 白名单没放开就拦截了。解决：开发阶段把 CORS 中间件配置成允许所有来源，上线前再收紧。
问题三：发帖正常，但列表页一直看不到新内容。这大概率是缓存没删干净。CreatePost 里删的缓存 key 是 post:list:hot，但列表接口里还可能有 post:list:new 之类的其他 key。解决：发帖时用前缀批量删除，或者把所有列表缓存 key 统一成一个函数管理。
问题四：admin 接口提示无权限，但管理员账号明明登录了。检查签发 token 时 claims 里有没有写入 role 字段。如果 JWT 生成代码只在登录时写入了 UserID 和 Username，那 AdminAuth 里 claims.Role 永远为空。解决：在签发时补充 role 字段，并重新签发 token。
问题五：swagger 文档生成后接口调不通，报 404。确认 swagger 路由是否注册到了 router.go 的引擎上。docs.go 生成后要导入到 main.go 或 router.go 中，并把静态资源目录指向 docs 文件夹，漏掉这一步文档页面会直接 404。
6. 二次开发：给论坛加一个“点赞”功能的完整改法
6.1 数据层改动：count字段还是独立like表
最常见的两种做法是帖子表加 like_count 字段，或者新建 post_like 表记录用户和帖子的关系。前者查询简单，但没法做去重判断，用户是否点过赞得另外查缓存；后者能精确记录关系，但要控制点赞总数的读取方式。我一般会建议两个都用：post_like 表存关系，帖子表冗余 like_count 字段做计数展示。插入点赞记录时先判断是否已存在，不存在则插入并把帖子表的 like_count 加一。
6.2 接口层与业务层联动：从路由到service一条线
改造涉及 post 模块的三个文件。models 里加 Like 结构体，service 里加 LikePost 方法，router 里挂 POST /like 和 POST /unlike 两个接口。点赞方法的核心逻辑是事务内完成关系写入和计数更新，Redis 缓存直接删除让列表下一次回源重建。小程序端拿到点赞状态后，把按钮切换成高亮，随请求带上 post_id 即可。discover 数据一致性的关键点：删除缓存放在事务提交之后，否则并发请求可能读到旧缓存。
如果还要做“我赞过的帖子”页面，只需在 post_like 表按 user_id 查询帖子ID集合，再批量拉取帖子详情。这样最省事，一个索引就能解决。整套改造做完，从数据库到接口大约三个文件、一百行代码就落地了。
从那以后，我每次改这套论坛代码都会强制走一遍三件事：先跑 swagger 里的接口做回归，再造几条假数据打一遍列表和缓存的组合场景，最后真机微信开发者工具里过一遍页面。这三步踩过不少坑，有一次漏了清理缓存键，测试环境里帖子列表两天没更新，排查了大半天才意识到是缓存捣的鬼。从那以后缓存键的增删改都集中到一个文件里管理，再也没出过类似问题。希望帮到你。
本文还有配套的精品资源，点击获取
