go 发送邮件超时或被拒的根本原因是直接硬连公共 smtp 服务却忽略认证与限制：gmail 需开启两步验证并用 app password，163 要启用 smtp 并填授权码；发信地址必须与登录账号一致；gopsutil 的 cpupercent 首次调用为 0，需间隔采样；告警重复发送需用状态变量限频。
Go 发送邮件为什么总是超时或被拒？
根本原因不是代码写错了，而是多数人直接用 smtp.SendMail 硬连 Gmail/163 这类公共 SMTP 服务，却忽略了它们的认证要求和限制策略。Gmail 默认禁用“不够安全的应用”，163 要求开启 SMTP 并使用授权码而非密码，且部分服务商对未加密连接直接拒绝。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
gomail库（比原生net/smtp更健壮），它自动处理 AUTH、STARTTLS 和编码问题 - SMTP 地址、端口、账号必须匹配服务商要求：比如 163 是
smtp.163.com:465（SSL）或:587（STARTTLS），不能混用 - 密码字段填的是“授权码”，不是邮箱登录密码；Gmail 需在 Google 账户里开启两步验证并生成 App Password
- 发信地址（
From）必须和登录账号一致，否则 163/Gmail 会静默丢弃
监控 CPU 内存时，gopsutil 的 CPUPercent 为什么返回 0 或不准？
因为 CPUPercent 是采样差值，首次调用永远是 0，且需要间隔一定时间（如 2 秒）再调第二次才能出有效值。新手常把它当“瞬时读数”用，结果告警逻辑全乱。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 初始化后先 sleep 2 秒，再调一次
CPUPercent获取真实值；或用cpu.Times(false)手动算差值 - 内存监控别只看
Mem.VirtualMemory()的Percent，它不含 cached/buffer，实际压力可能被低估；建议同时检查Available绝对值（单位字节），比如低于 512MB 就触发告警 - Linux 下
gopsutil依赖/proc，容器环境若挂载不全（如没挂/proc），会返回空或错误，需确认容器权限
告警触发后重复发邮件怎么停？
最常见错误是把告警逻辑写在主循环里，每次资源超标就无条件调一次发送函数，导致一分钟发几十封。这不是“功能没做”，而是缺少状态跟踪。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用一个全局变量（如
lastAlertTime map[string]time.Time）记录每种告警（"cpu_high"、"mem_low"）上次触发时间 - 每次检测前先查：如果距上次告警不足 5 分钟（
time.Since(lastAlertTime["cpu_high"]) ），直接跳过发送 - 发送成功后再更新
lastAlertTime["cpu_high"] = time.Now()；失败则不更新，避免漏告 - 不要用文件或数据库存状态——简单工具就该轻量，内存 map 足够；进程重启后告警可重置，符合预期
编译成二进制后，在 CentOS 7 上运行报 version GLIBC_2.28 not found
这是 Go 默认用宿主机（比如你开发用的 Ubuntu 22.04）的 CGO 环境链接，而 CentOS 7 自带的 glibc 太老。不是代码问题，是构建环境没隔离。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 关掉 CGO：
CGO_ENABLED=0 go build -o alertor main.go，这样生成纯静态二进制，不依赖系统 glibc - 如果用了
gopsutil，它默认启用了 CGO（为了读取 /proc 更准），需显式关掉：CGO_ENABLED=0 go build -tags "purego" -o alertor main.go - 验证是否生效：用
ldd alertor检查输出，如果是 “not a dynamic executable”，就对了 - 别在 Docker 里交叉编译还开 CGO——哪怕 base 镜像用 alpine，只要开了 CGO 就可能链到宿主机头文件
真正难的不是写发送邮件或读 CPU，是让这俩在目标机器上稳定跑起来。很多坑不在 Go 语法里，而在 SMTP 策略、/proc 权限、glibc 版本这些边界上。
