最常踩的坑是惯性沿用Python“进程即服务”模式，导致OOM、goroutine泄漏、信号未处理、日志卡死及重启后连接池复用旧配置；需显式管理goroutine生命周期、调用http.Server.Shutdown、关闭监听器和连接池，并注册SIGTERM/SIGINT信号处理器。
Python Web服务转Go常驻内存运行，最常踩的坑不是语法错误，而是把Python那套“进程即服务”的惯性直接搬过去——结果程序跑着跑着就OOM、goroutine泄漏、信号没处理、日志卡死，甚至重启后连接池还在用旧配置。
goroutine泄漏：没等完就return
Python里异步少，HTTP handler返回即结束；Go里但凡启了goroutine又没加控制，它就可能一直挂着。常见于日志上报、监控打点、后台任务触发这类“fire-and-forget”逻辑。
- 错误写法：
go sendMetric(data)—— 函数返回后，sendMetric还在跑，参数data可能已失效，goroutine也永远不会被回收 - 正确做法：用带超时的
context.WithTimeout包裹，或改用带缓冲的channel+worker池统一调度 - 验证方式：压测后查
runtime.NumGoroutine()，持续上涨就是泄漏信号
HTTP服务器没关干净：连接池+监听器残留
Python Flask/Uvicorn靠进程管理工具（如systemd）杀进程就完事；Go里http.Server要自己调Shutdown()，否则旧连接不关闭、新连接抢不到端口、TLS证书热更失败。
- 必须显式调用
srv.Shutdown(context.WithTimeout(...))，不能只srv.Close() - 监听器
net.Listener要defer ln.Close()，否则bind: address already in use反复出现 - 全局连接池（如
sql.DB、redis.Client）需在Shutdown回调里调Close()，否则连接堆积
信号处理不完整：SIGTERM被忽略或阻塞
Linux容器环境发SIGTERM要求优雅退出，但Go默认不注册信号处理器。Python靠gunicorn/uvicorn内置处理，Go得自己写。
立即学习“Python免费学习笔记（深入）”；
- 漏掉
syscall.SIGINT会导致本地Ctrl+C无法中断，只能kill -9 - 在
signal.Notify后没用select{case 阻塞等待，导致主goroutine提前退出，后台goroutine被粗暴终止 - 关键资源（如文件句柄、DB连接）释放逻辑必须放在信号处理分支里，不能只写在
main()末尾
日志与标准输出混用：stdout阻塞导致整个HTTP handler卡住
Python里print打日志很随意；Go里fmt.Println写到stdout，而Docker或systemd会把stdout重定向到管道——一旦下游消费慢（比如日志收集agent卡住），整个Write()就阻塞，所有HTTP handler停摆。
- 禁止在handler里直接用
fmt.Print*或log.Print*（除非你确认log.SetOutput已设为非阻塞writer） - 推荐用
zap或zerolog，它们默认使用无锁buffer+异步flush - 若必须用
log包，至少包装一层带timeout的io.Writer，避免无限hang住
真正难的不是写个能跑的Go服务，而是让这个服务在7×24小时常驻过程中，不因一次panic、一次信号、一次慢日志而连锁崩溃。这些点看似琐碎，但线上出问题时，90%都落在上面几处。
