用requests获取HTTP状态码比ping更靠谱，因ping仅检测ICMP连通性，而宕机常发生在Web服务层；需设timeout、禁重定向、检查200–299范围、处理各类异常并记录日志。
用 requests 获取状态码比 ping 更靠谱
网站“宕机”不等于网络不通，ping 只能测 ICMP 连通性，而真实问题常出在 Web 服务层（比如 Nginx 启动了但应用崩了、HTTPS 证书过期、反向代理返回 502）。所以监控必须走 HTTP 请求，拿到 status_code 才算数。
常见错误是写个 os.system("ping -c1 example.com") 就以为万事大吉——它根本不会告诉你 503 Service Unavailable。
- 用
requests.get(url, timeout=10)，别省略timeout，否则请求卡住会拖垮整个定时任务 - 加
allow_redirects=False避免被跳转干扰判断（比如监控登录页却被重定向到首页） - 检查
r.status_code是否在[200, 299]范围，别只写== 200 - 如果目标强制 HTTPS，记得 URL 写全
https://，否则可能被 301 重定向或直接失败
用 smtplib 发邮件前先确认 SMTP 服务可用
告警邮件发不出去，等于没监控。最常踩的坑不是代码写错，而是本地没配好 SMTP 凭据或服务商限制了非网页端登录。
比如 Gmail 默认禁用“不够安全的应用”，得手动开 App Password；国内企业邮箱常要求开启 SMTP 服务并单独授权。
立即学习“Python免费学习笔记（深入）”；
- 测试时先用
smtplib.SMTP_SSL("smtp.gmail.com", 465)直连，别用starttls()增加复杂度 - 用户名填完整邮箱（如
"alert@example.com"），密码用应用专用密码，不是账号登录密码 - 发件人和收件人地址都必须是字符串，不能是列表；多个收件人用逗号拼接字符串，别传 list 给
sendmail() - 邮件正文用
MIMEText(..., _charset="utf-8")，否则中文变乱码
用 schedule 或 APScheduler 定时，别用 time.sleep()
while True: check(); time.sleep(60) 看似简单，但进程一挂就停，也没日志、没错重试、没法动态改间隔——生产环境基本不可用。
schedule 轻量够用，APScheduler 支持持久化和多线程，按需选。
-
schedule.every(5).minutes.do(check_website)比手写循环更稳，且支持.tag("prod")分组管理 - 加个
try/except包住check_website()，否则一次异常会让后续所有任务停止 - 每次运行前打印时间戳和状态码，比如
print(f"[{datetime.now()}] {url} → {r.status_code}")，排查时不用翻日志 - 别把邮件发送逻辑塞进检查函数里——失败要重试，但状态检查本身不该因此阻塞下一轮
域名解析失败、SSL 验证失败这些边界情况必须显式处理
真实环境中，requests.get() 不只是返回 4xx/5xx，更多时候是直接抛异常：requests.exceptions.ConnectionError（DNS 解析失败、目标关机）、SSLError（证书过期、自签名）、Timeout（后端卡死）。
这些异常如果不 catch，脚本就退出，告警彻底失效。
- 统一捕获
requests.RequestException，它覆盖所有 requests 异常子类 - 对
SSLError单独处理：如果是自建服务且可接受不验证书，加verify=False（但记得加警告日志） - DNS 失败时，
ConnectionError的str(e)通常含"Name or service not known"，可据此区分是域名问题还是服务问题 - 记录异常类型和
repr(e)到日志，比只打 “failed” 有用得多
真正的难点不在怎么发邮件或怎么定时，而在于你是否真的见过凌晨三点 DNS 突然解析失败、证书凌晨两点过期、云厂商 LB 静默丢包——这些 case 都得在代码里留一道缝，而不是等它炸了再补。
