邮件监听必须用IMAP，因其支持UNSEEN标志和UID持久标识；POP3下载即删不可靠；需用imaplib或imapclient，Gmail需App密码，OAuth2邮箱需msal配合；判断特定邮件须组合自定义Header、时间窗口与发件人白名单；处理后记录UID防重；重启应通过无密码sudo或systemd触发；脚本需异常重试、状态通知及长连接管理。
邮件监听必须用 IMAP，不能靠本地收件箱轮询
Python 本身不自带邮件服务器，所谓“收到邮件”实际是定期连接邮箱 IMAP 服务（如 Gmail、Outlook、企业 Exchange）拉取新邮件。POP3 不适合——它通常下载即删，无法可靠标记已处理；IMAP 支持 UNSEEN 标志和 UID 持久标识，是唯一可行路径。
常见错误是直接监听本地 .eml 文件或 Outlook 桌面客户端的收件箱，这在服务器环境几乎不可靠：没有后台进程支撑、权限受限、GUI 依赖强。
- 必须使用
imaplib（标准库）或更易用的imapy/imapclient（需 pip 安装） - Gmail 需开启「App 密码」并关闭两步验证的默认拦截，否则
LOGIN直接被拒 - 企业邮箱若强制 OAuth2（如 Microsoft 365），就不能用密码登录，得走
oauth2流程，imaplib原生不支持，得用msal+imaplib手动拼 Authorization header
怎么判断“特定邮件”——别只比 subject，要组合多条件
单靠 subject 包含 “reboot” 就触发，极易误杀：别人转发的旧工单、测试邮件、甚至垃圾邮件带关键词都会中招。真正可控的方式是要求发件人配合，在邮件里埋唯一标识。
推荐方案：约定一个自定义邮件头（如 X-Trigger-Action: server-restart）+ 时间窗口校验（10 分钟内新邮件）+ 发件人白名单（FROM 必须是 admin@company.com）。
立即学习“Python免费学习笔记（深入）”；
- IMAP 的
SEARCH命令不支持自定义 header 过滤，得先FETCH邮件头再 Python 侧解析，避免全量下载正文 - 用
email.parser.Parser().parsestr()解析原始 header，不要用message.get('X-Trigger-Action')——有些服务会过滤未知 header - 务必记录已处理邮件的
UID到文件或 SQLite，防止重启脚本后重复触发（IMAP 的UNSEEN在不同客户端间不同步）
服务器重启不能直接调 os.system(‘reboot’) —— 权限和上下文全错
Python 脚本一般以普通用户运行，os.system('sudo reboot') 会卡在密码输入，且 sudo 默认禁止非 tty 环境执行特权命令。硬编码密码更危险，违反最小权限原则。
正确做法是把重启动作交给系统级机制，Python 只负责“通知”：
- 写一个无密码 sudo 规则：
echo "myuser ALL=(ALL) NOPASSWD: /sbin/shutdown -r now" | sudo tee /etc/sudoers.d/reboot-trigger - 或者用 systemd 服务：写个
trigger-reboot.service，Python 用subprocess.run(['systemctl', 'start', 'trigger-reboot.service'])触发 - 绝对不要在脚本里写
time.sleep(5); os.system('reboot')——邮件处理线程还没退出就关机，日志丢失、锁文件残留、IMAP 连接中断都可能让下次启动失败
守护与容错：没人盯着脚本，它就得自己活下来
这个脚本一旦部署，就得 7×24 运行。但网络抖动、邮箱临时不可达、IMAP 连接超时、SSL 证书更新都会让它挂掉——而你不会立刻知道。
- 用
while True:包裹主循环，每次失败后time.sleep(60)再试，别用except Exception as e: pass吞掉所有异常 - 每次成功处理邮件后，向企业微信/钉钉发一条
requests.post()通知，内容包含触发时间、发件人、邮件 UID——这是唯一能确认它还在干活的证据 - Linux 下用
systemd管理：设Restart=always、StartLimitIntervalSec=0，避免进程退出后无人拉起
最常被忽略的是 IMAP 连接复用：每次循环都新建 imaplib.IMAP4_SSL 对象再登录，容易被邮箱服务商限流（Gmail 默认 10 次/秒）。保持长连接、定期 IDLE 或 NOOP 心跳才是生产级写法。
