Flask应用生产环境报错未被Sentry捕获，主因是初始化时机错误（须在app创建后、启动前调用sentry_sdk.init）、异常未处于HTTP请求生命周期内（如Celery/线程异常需手动capture_exception）、Gunicorn worker被kill-9或OOM终止导致上报失效、send_default_pii默认关闭致关键上下文丢失，以及多worker下任一进程未正确初始化SDK。
Flask应用在生产环境报错没被Sentry捕获，绝大多数情况不是SDK没装，而是初始化时机、异常传播路径或运行环境干扰导致的。关键得看异常是否真走到了Sentry能钩住的地方。
FlaskIntegration是否在app创建后立即生效
FlaskIntegration依赖Flask的信号机制（比如request_started、got_request_exception），它必须在Flask应用实例创建完成、且所有中间件/扩展加载完毕之后调用sentry_sdk.init()，否则信号钩子注册失败。
- 错误做法：在导入模块时就初始化SDK，此时
app对象还没构造，FlaskIntegration无法绑定到任何实际app - 正确做法：确保
sentry_sdk.init()在app = Flask(__name__)之后、且app.run()或WSGI容器（如Gunicorn）启动前执行 - 常见陷阱：使用工厂函数模式时，在
create_app()内部初始化，但忘了检查是否已初始化过（重复init会静默失败）
Celery或threading中抛出的异常不会自动上报
FlaskIntegration只捕获HTTP请求生命周期内的异常；Celery任务、后台线程、定时任务里的ZeroDivisionError等，Sentry默认完全看不见。
- 必须在任务函数内部手动捕获并上报：
sentry_sdk.capture_exception() - Celery推荐加
CeleryIntegration，但它只对@celery.task装饰的任务有效，对threading.Thread或concurrent.futures仍需手写try/except - 异步任务里未加
capture_exception()，即使DSN配置正确，Sentry Dashboard也绝对为空
Gunicorn worker被kill时根本来不及发事件
当Gunicorn worker因超时（--timeout）、OOM被Linux OOM Killer干掉，或进程被kill -9强制终止时，Python解释器直接退出，sentry_sdk的异步发送线程根本没机会刷出缓冲区。
立即学习“Python免费学习笔记（深入）”；
- 这类崩溃在Sentry里“零记录”，但系统日志（
/var/log/syslog或journalctl -u gunicorn）里会有Killed process字样 - 不能依赖Sentry兜底，必须配合
systemd的Restart=always+StartLimitIntervalSec，或Supervisord的crash日志 - 可临时加
atexit.register(sentry_sdk.flush)，但对kill -9和OOM无效
本地变量缺失或敏感字段被过滤
堆栈里看不到request.args、user.id或数据库查询参数？不是SDK坏了，是Sentry默认主动剥离了所有可能含PII的数据。
-
send_default_pii=False（默认值）会清空request.headers、request.cookies、request.environ中的敏感键 - 开启
send_default_pii=True有风险，必须搭配before_send回调过滤真实密码、token字段 - 想看
request.json内容？得自己在before_send里显式提取并注入event['extra']，否则永远为空
最常被忽略的是：Gunicorn多worker场景下，每个worker进程都得独立初始化Sentry SDK，且dsn不能为None或空字符串——哪怕只漏一个worker，那一半流量的错误就彻底消失了。
