Sentry在自动化脚本中需显式启用tracing并手动flush：必须设置enable_tracing=True、traces_sample_rate控制采样，environment区分环境，except中调用capture_exception(e)，最后执行sentry_sdk.flush(timeout=5)确保上报。
直接在自动化脚本里加 sentry_sdk.init() 不够——Sentry 默认不捕获未处理异常以外的错误，而很多 Python 自动化脚本（比如 cron 任务、CLI 工具）会静默失败或被 sys.exit() 中断，根本触发不了上报。
初始化时必须设置 enable_tracing=True 和 traces_sample_rate
单纯调用 sentry_sdk.init(dsn="...") 只能捕获顶层未处理异常。自动化脚本常包含子命令、异步任务、重试逻辑，这些内部抛出的异常容易漏报。开启 tracing 才能让 Sentry 捕获上下文链路，并配合采样率避免日志爆炸：
-
enable_tracing=True是关键开关，否则with sentry_sdk.start_transaction()无效 -
traces_sample_rate=0.1适合低频脚本；高频任务建议用traces_sampler函数按 error 级别 100% 采样 - 务必传入
environment（如"prod-cron"），否则不同部署环境的事件混在一起，排查时分不清是测试还是生产脚本挂了
手动捕获已处理异常：别依赖 except 后自动上报
Sentry 不会自动捕获你 try/except 里吞掉的异常——这是最大误区。自动化脚本里大量使用 except Exception as e: 做容错，结果错误悄无声息消失。
- 显式调用
sentry_sdk.capture_exception(e)，不是capture_message() - 在
except块末尾加这句，且确保e是原始异常对象（别传字符串） - 如果用了
logging.exception()，可配sentry_sdk.integrations.logging.LoggingIntegration(event_level=logging.ERROR)，但注意它只捕获ERROR级别以上日志，WARNING不会上报
确保进程退出前 flush 上报数据
脚本执行完立即退出，Sentry 的异步发送线程可能来不及发出去——尤其短生命周期的 cron 任务，90% 的“没收到报警”都卡在这儿。
立即学习“Python免费学习笔记（深入）”；
- 在脚本最后（或
atexit钩子里）调用sentry_sdk.flush(timeout=5) -
timeout设为 5 秒足够；设太小（如 1）可能丢数据，设太大（如 30）会拖慢任务调度 - 如果脚本可能被
os._exit()或信号强制终止（如 SIGTERM），需注册signal.signal(signal.SIGTERM, ...)处理器来提前 flush
最常被忽略的是 flush 时机和 tracing 开关——没开 tracing，再细的异常堆栈也看不到上下文；没 flush，报错就石沉大海。这两点不落实，Sentry 在自动化场景里基本等于摆设。
