goroutine 启动后立即返回，通知逻辑须独立封装并增强可观测性：加日志、重试、错误回调；修复闭包变量捕获问题；防止泄漏需设超时与资源清理；并发需限流与合并，避免压垮下游。
goroutine 启动后立即返回，通知逻辑必须独立封装
Go 的 go 关键字启动 goroutine 是非阻塞的，调用方不会等待执行完成。如果通知逻辑（比如发 HTTP 请求、写日志、推送消息）放在 goroutine 里但没做错误隔离或状态反馈，失败时完全静默——你根本不知道它挂了。
常见错误是直接这么写：
go sendNotification(user.ID, "order_created") // 万一网络超时？panic？没人管
正确做法是把通知包装成可观察的单元：加日志、加重试、加简单错误回调。例如：
- 用带 context 的 HTTP client，设置超时（
http.DefaultClient.Timeout = 5 * time.Second不够安全，应为每个请求单独设） - 捕获 panic，用
recover()防止整个程序被拖垮 - 关键通知（如支付成功）建议记录发送状态到 DB 或发到消息队列，而非只依赖内存中的一次 goroutine
避免在 goroutine 中访问已失效的局部变量
闭包捕获变量时，容易误以为 goroutine 拿到的是“当前值”，实际捕获的是变量地址。循环中启动多个 goroutine，常导致所有 goroutine 共享最后一个迭代的值。
典型翻车代码：
for _, user := range users {
go func() {
notify(user.Email) // user 是循环变量，所有 goroutine 最终都用最后一个 user
}()
}
修复方式只有两种：
- 传参：把
user显式作为参数传入匿名函数：go func(u User) { notify(u.Email) }(user) - 局部拷贝：在循环体内定义新变量：
u := user; go func() { notify(u.Email) }()
别依赖编译器优化或侥幸心理——Go 1.22 依然如此，这是语言规范行为。
goroutine 泄漏比想象中更容易发生
异步通知若涉及 channel、timer、HTTP 流或数据库连接，没设超时或没关闭，goroutine 就会永远卡住。pprof 查到几百个 runtime.gopark 状态时，八成是这类泄漏。
几个高危场景：
- 用
time.After()做超时但没 select 到底——它背后是个永不关闭的 timer goroutine - HTTP 客户端没设
Timeout或Transport.IdleConnTimeout，连接池耗尽后新请求无限阻塞 - 向无缓冲 channel 发送数据，但没有 goroutine 在另一端接收，发送方永久阻塞
推荐组合：用 context.WithTimeout() 包裹整个通知流程，并在 defer 里 cancel；channel 操作一律配合 select + default 或超时分支。
并发量大时，裸用 goroutine 会压垮下游服务
每来一个订单就 go sendEmail()，QPS 上千时可能瞬间发起上千 SMTP 连接，邮件服务商直接限流或拉黑 IP。
这不是 goroutine 本身的问题，而是缺乏流量整形。简单方案有：
- 用带缓冲的 channel 做节流：声明
notifyCh = make(chan Notification, 100)，另起一个 goroutine 消费并限速（如每秒最多 10 条） - 用第三方库如
golang.org/x/time/rate的Limiter控制速率 - 对同一用户的通知合并（如 5 秒内多次下单，只发一次汇总通知），这需要额外的状态管理，不能靠 goroutine 单独解决
异步不等于无序，更不等于无约束。真正的生产级通知机制，goroutine 只是执行单元，调度、限流、重试、可观测性都得另外搭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
