最可靠方式是直接调用 register_error_handler(500, handler)，handler需提取真实异常栈、构造带timestamp/sign的钉钉json报警体，异步发送并设超时，失败时本地记日志，仅生产环境启用且避免硬编码webhook。
用 register_error_handler 捕获全局 500 错误
Flask 不会自动把未处理异常发到外部服务，必须显式注册错误处理器。直接在应用实例上绑定 register_error_handler(500, handler) 是最可靠的方式，比依赖 @app.errorhandler(500) 更稳妥（后者在蓝本中可能失效）。
常见错误是只监听 Exception 或漏掉异步发送逻辑导致响应阻塞——钉钉 Webhook 调用必须设超时，否则用户请求卡住。
- 确保 handler 函数接收一个
error参数（类型为InternalServerError或其子类） - 从
sys.exc_info()或error.original_exception提取真实异常栈（error本身不带 traceback） - 不要在 handler 里做耗时操作；建议用
threading.Thread或异步 HTTP 客户端（如httpx.AsyncClient配合loop.create_task）
构造符合钉钉要求的 JSON 报警体
钉钉自定义机器人要求 POST 到 Webhook URL 的 body 是特定格式的 JSON，且必须带 timestamp 和 sign（如果启用了签名验证）。漏掉签名或时间戳偏差超过 1 小时会导致 403。
关键字段：用 text.content 放精简错误摘要（含 HTTP 方法、路径、状态码），用 markdown.title 做标题，正文用 markdown.text 包含完整 traceback（注意转义换行符为 \n）。
-
timestamp必须是字符串格式的秒级时间戳（str(int(time.time()))） - 若启用签名，
sign是hmac.new(secret.encode(), (timestamp + "\n" + secret).encode(), digestmod=hashlib.sha256).digest().base64() - traceback 字符串建议用
traceback.format_exception(*sys.exc_info())获取，避免截断
用 requests.post 发送报警并处理网络失败
别假设钉钉接口永远可用。网络超时、DNS 失败、钉钉限流（每分钟最多 20 条）都可能导致报警丢失。必须加 timeout=(3, 7)（连接 3 秒，读取 7 秒），并捕获 requests.exceptions.RequestException。
更关键的是：失败日志必须写本地（比如用 app.logger.error），否则钉钉挂了你连问题都发现不了。
- 检查响应状态码：
resp.status_code != 200时记录 resp.text（钉钉返回的错误提示常含具体原因） - 避免重试——重复报警比漏报更干扰运维；失败就记日志，不重发
- Webhook URL 必须配置为环境变量（如
os.getenv("DINGTALK_WEBHOOK")），禁止硬编码
区分开发与生产环境，避免测试污染报警群
本地调试时触发 500 却弹到线上钉钉群，是高频事故。最简单办法是加环境判断：只有 os.getenv("FLASK_ENV") == "production" 才发 Webhook。
但更健壮的做法是单独配一个开关变量（如 DINGTALK_ALERT_ENABLED），默认 False，上线时再开启。顺便提醒：Flask 2.3+ 已弃用 FLASK_ENV，推荐用 FLASK_DEBUG 或自定义变量。
- 开发时可把报警内容打印到控制台（
print(json.dumps(payload, indent=2))），方便验证格式 - 测试异常场景用
curl -X GET http://localhost:5000/raise-500触发，别等真崩了才测 - 注意 Flask 的
PROPAGATE_EXCEPTIONS设为 True 时，某些异常不会进 500 handler——确保它为 False（默认值）
真正难的不是发一次消息，而是让报警既不淹没人、又不漏关键错误。比如异步发送线程没加守护（daemon=True），进程退出时可能丢最后一条；或者 traceback 过长被钉钉截断——这些细节不验证就上线，迟早半夜被叫醒。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
