go

我们公司有一款社交 App，随着业务不断扩展，功能逐渐增多，早期的代码发展至今写的很乱很臃肿。为此，我们对部分业务模块进行了重构，比如里面的推送相关的服务被单独拆分了出来。 像「用户资料审核通过

刚开始学 Go 的我们也许还停留在 CRUD 和 gin 接口。但当我们始接触并发任务处理、资源保护、稳定性设计时，一个能复用的协程池。。。

在上一篇文章中，我们已经完成了定时任务系统的初步搭建，实现了从静态任务注册到动态任务调度的完整流程，并且支持了任务执行日志的自动记录。 不过，在实现过程中，我们也发现了一些存在的问题： 任务并发

在项目初期，或者公司业务规模较小时，定时任务往往直接集成在项目框架的代码中，或者简单地部署在 Linux 服务器上执行。虽然这种方式实现起来简单直观，但随着业务需求的不断增长，每当需要新增、修改

在之前的几篇文章中，我们已经完成了 Gin 框架的基本入门，涵盖了用户模块的增删改查、Redis 缓存使用、统一响应结构封装等重要功能模块。经过这些基础模块的搭建，我们的项目框架已经有了一个稳固

在前面几篇文章中，我们已经完成了用户模块的增删改查接口、统一响应结构的封装、数据库和日志模块的配置化管理等核心功能。随着项目的逐步完善，我们的系统也开始处理越来越多的请求。在这个过程中，我们就需

在前面的章节中，我们已经完成了以下模块的封装： 用户模块的增删改查 通用分页 + 统一响应结构 zap + lumberjack 封装的日志模块 但是目前仍然存在一个“隐患”： 我们将很多重要的

在完成了用户模块 CRUD、统一响应结构与错误码、分页封装之后，我们已经搭建出一个较为完整的 Gin 项目基础骨架。 但要想让项目在生产环境中更加可观测、易排查、可追踪，日志模块就必不可少了。

在前面几篇中，我们已经完成了用户模块的注册、查询、更新、删除，以及分页查询接口。过程中我们也写了分页结构体、统一的接口返回方法，看起来也还挺顺手的。 但写着写着就会发现，有些东西我们在每个接口里

我们之前已经实现了简单的用户注册逻辑，这篇文章我们就把其他的增删改查接口都给加一下。 1. 查询用户信息 POST /info） 我们来实现一个获取用户详情的接口：根据 ID 查询用户信息，并返

在上一篇中，我们实现了将用户注册信息写入 MySQL 数据库的完整流程，接口也已经能够正常接收参数并写入数据表。 但是我们可能也注意到了：我们并没有对请求参数做任何校验。 这意味着，哪怕用户提交

在上一篇中，我们已经实现了一个可以接收 JSON 请求的 /register 接口。那我们既然可以正常拿到请求参数 我们是不是就可以进一步完善功能，将用户数据真正写入 MySQL 数据库。 项目

继上一篇我们学习了如何通过 GET 接口接收 URL 参数，今天我们继续来写一个 POST 接口，学习如何在 Gin 中接收 JSON 请求数据，并返回响应。 Gin 中常见的参数接收方式 在我

首先写这系列文章，是为了记录刚开始自己学习 Gin 框架的过程。 我并没有打算一开始就搭建一个成熟的项目骨架，毕竟对整个框架还不是特别熟悉，也没有用什么高级插件或第三方库。就是从最基础的内容开始，一