在 Go 应用中，可通过 go 关键字将后台任务（如 Redis 监听、定时检查）异步启动，与 HTTP 服务共存；但必须避免空循环、合理管理生命周期，并分离关注点以保障稳定性与可维护性。
在 go 应用中，可通过 go 关键字将后台任务（如 redis 监听、定时检查）异步启动，与 http 服务共存；但必须避免空循环、合理管理生命周期，并分离关注点以保障稳定性与可维护性。
Go 的并发模型天然适合“服务监听 + 后台协程”这种典型架构：HTTP 服务器本身由 net/http 自动为每个请求分配 goroutine，而长期运行的后台任务（如监听 Redis Pub/Sub、轮询状态、清理过期缓存）则应显式启动独立 goroutine 执行。但简单地 go checkExpire() 并不足够——需兼顾资源安全、错误处理、优雅退出和连接复用。
✅ 正确做法：结构化启动 + 生命周期意识
以下是一个生产就绪的示例，整合了 HTTP 服务、Redis Pub/Sub 监听，并规避常见陷阱：
package main
import (
"context"
"fmt"
"log"
"net/http"
"time"
"github.com/go-redis/redis/v8"
)
var ctx = context.Background()
var rdb *redis.Client
func initRedis() {
rdb = redis.NewClient(&redis.Options{
Addr: "localhost:6379",
Password: "",
DB: 0,
})
if _, err := rdb.Ping(ctx).Result(); err != nil {
log.Fatal("Failed to connect to Redis:", err)
}
}
// 后台任务：监听 Redis 频道，解耦消息接收与业务处理
func startRedisListener() {
pubsub := rdb.Subscribe(ctx, "notifications")
defer pubsub.Close() // 确保连接释放
// 使用带缓冲的 channel 解耦接收与处理，防止阻塞导致丢消息
msgCh := make(chan *redis.Message, 100)
// 接收 goroutine：非阻塞读取消息
go func() {
for {
msg, err := pubsub.ReceiveMessage(ctx)
if err != nil {
log.Printf("Redis receive error: %v", err)
return
}
select {
case msgCh <h3>⚠️ 关键注意事项</h3>
-
禁止空循环（
for {}）：它会 100% 占用一个 CPU 核心，属于严重反模式。应使用time.Sleep、select { case 或 <code>context.WithTimeout控制等待。 -
Pub/Sub 连接需专用 client：不要与普通命令 client 共享连接池（如
rdb.Get()和rdb.Subscribe()混用），否则易因连接池争抢导致订阅超时。推荐为 Pub/Sub 单独初始化 client 并设置PoolSize: 1。 -
务必调用
defer pubsub.Close()：否则连接泄漏，Redis 侧堆积 SUBSCRIBE 连接，最终触发maxclients限制。 -
消息处理必须解耦：
pubsub.Channel()或pubsub.ReceiveMessage()返回后，应通过 channel 或 worker pool 异步处理，避免阻塞接收循环。 -
主 goroutine 不应退出：
http.ListenAndServe是阻塞调用，若其返回（如因 error 或 shutdown），应用应主动关闭后台 goroutine（建议引入context.Context实现优雅终止）。
✅ 总结
启动后台任务的正确姿势不是“加个 go 就完事”，而是：
? 显式分离「接收」与「处理」逻辑；
? 使用缓冲 channel 或 worker pool 抗峰值；
? 为不同语义的连接（命令 vs. Pub/Sub）配置独立 client；
? 所有长连接操作配 defer Close()；
? 主流程通过 ListenAndServe 阻塞维持程序存活，而非依赖 select{} 或 time.Sleep 空转。
这样构建的 Go 后端，既简洁又健壮，真正发挥出 goroutine 轻量、channel 安全、生态成熟的核心优势。
