在 go 中，若需让 goroutine 持续监听 channel（如路由变更事件），必须确保主 goroutine 不提前退出；否则所有子 goroutine 会被强制终止，导致看似“未执行”的假象。
在 go 中，若需让 goroutine 持续监听 channel（如路由变更事件），必须确保主 goroutine 不提前退出；否则所有子 goroutine 会被强制终止，导致看似“未执行”的假象。
Go 的程序生命周期由 main 函数所在的 goroutine 决定：一旦 main 函数返回，整个进程立即退出，所有其他 goroutine 会被无条件终止——无论它们是否正在处理 channel 接收、网络请求或定时任务。这正是你调用 go getRoutes() 后“函数似乎没被调用”的根本原因：main 迅速结束，goroutine 来不及执行第一轮 range 循环即被回收。
✅ 正确做法：保持 main 活跃，并优雅控制退出
最简洁可靠的方式是使用一个 退出信号 channel，让 main 阻塞等待其关闭，而非盲目 for {} 死循环：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func main() {
exit := make(chan struct{}) // 使用 struct{} 节省内存，语义更清晰
// 启动监听 goroutine
go func() {
defer close(exit) // 确保异常退出时也能通知 main（可选）
for r := range rtu {
switch r.Type {
case 24:
fmt.Printf("Route added: %s via %s\n", r.Dst.String(), r.Gw.String())
case 25:
fmt.Printf("Route deleted: %s via %s\n", r.Dst.String(), r.Gw.String())
}
}
}()
// 主 goroutine 阻塞等待退出信号
<-exit
fmt.Println("Listener stopped. Exiting gracefully.")
}? 关键说明：
rtu必须是一个已初始化且不会被关闭的 channel（例如由netlink库持续写入的路由更新通道）；若rtu被关闭，range会自然退出，exitchannel 随之关闭，main继续执行后续逻辑。- 使用
struct{}类型的 channel 是 Go 社区惯例：零内存占用，明确表达“仅传递信号”意图。- 避免
for {}或time.Sleep(1 等粗暴方式——它们浪费 CPU 或掩盖真实退出逻辑。
⚠️ 注意事项与最佳实践
-
不要依赖
runtime.Goexit()或os.Exit()在子 goroutine 中终止程序：这会跳过defer、资源清理，且无法被上层捕获。应始终通过 channel 通知main做统一退出。 -
若需多路退出控制（如 SIGINT + 超时 + 错误），改用
select+ 多 channel：select { case <-exit: fmt.Println("Exit signal received") case <-time.After(30 * time.Second): fmt.Println("Timeout reached") case <-sigChan: fmt.Println("Interrupt received") } -
务必确保
rtuchannel 的生产者已就绪：如果rtu尚未被任何 goroutine 写入，range会永久阻塞——这是预期行为，但需确认数据源已正确启动（例如netlink.RouteSubscribe()已调用）。
总之，Go 中“后台长期运行”的本质不是“让 goroutine 自己活下来”，而是设计好主 goroutine 的生命周期，使其主动等待子任务完成或响应退出指令。channel 是 Go 并发模型中协调这一关系的核心原语。
