sentry.init()必须在应用启动最早期调用，否则异常无法上报；需在请求中间件中提前绑定上下文，避免except块中补环境；调整max_value_length等参数防止栈帧截断；吞异常时须显式调用capture_exception()。
Python线上报错看不到完整栈？先确认 Sentry.init() 是否在最顶层执行
线上异常没上报，八成是初始化时机不对。Sentry 的 Sentry.init() 必须在应用启动最早期调用，比如 Django 的 settings.py 末尾、Flask 的主模块入口、或 WSGI/ASGI 启动脚本开头——不能塞在某个 view 或 class 里懒加载。
常见错误现象：logging 能打日志但 Sentry 完全收不到异常；或者只收到部分异常（比如只捕获了主线程的，协程/子线程/信号处理里的全丢了）。
- 确保
init()在任何业务代码 import 前完成，尤其避开循环 import 触发的延迟初始化 - Django 用户注意：别只在
INSTALLED_APPS里加sentry_sdk.integrations.django.DjangoIntegration就以为完事，Sentry.init()还得显式调 - 异步场景（如 FastAPI + Uvicorn）需额外传
integrations=[AsyncioIntegration()]，否则 await 中的异常静默丢失
用户环境变量传不上去？检查 before_send 和 scope.set_extra() 的使用位置
Sentry 默认只传基础运行时信息（Python 版本、OS、进程 ID），用户 ID、请求路径、设备型号这些得手动塞。但很多人把 scope.set_extra() 放在异常发生后才调，其实已经晚了——那时 scope 可能已被清理或复用。
正确做法是在请求生命周期开始时就绑定上下文，比如中间件里：
def sentry_context_middleware(get_response):
def middleware(request):
with sentry_sdk.configure_scope() as scope:
scope.set_extra("user_id", getattr(request.user, "id", None))
scope.set_tag("endpoint", request.resolver_match.view_name)
scope.set_context("request", {"path": request.path, "method": request.method})
return get_response(request)
return middleware
- 避免在
except块里用set_extra()补环境——异常可能跨多层调用，此时 scope 已不是当前请求的 -
before_send钩子适合过滤或脱敏（比如删掉password字段），不适合补充缺失字段，因为它触发时事件已构造完毕 - 若用 Celery，每个 task 需单独
configure_scope()，worker 进程不会自动继承主进程的 scope
报错堆栈被截断或显示 <frame object at>？关掉 max_value_length 限制
Sentry SDK 默认会截断长字符串和嵌套深的对象，导致关键变量值看不清，甚至整个 frame 显示成内存地址。这不是代码问题，是 SDK 的安全策略默认开启。
典型表现：本地复现能看清 locals 里的 user_data 内容，线上却只看到 <dict object at></dict>；或者 ValueError 报错信息只剩 “Invalid input”，后面具体哪行、哪个值出问题全没了。
- 初始化时加参数：
Sentry.init(..., max_value_length=8192)（默认 1024） - 对特别深的嵌套结构（如 DRF 序列化器输出），可设
max_depth=10（默认 5） - 注意性能影响：过大的
max_value_length会让上传 payload 暴涨，尤其带二进制或 base64 字段时，建议结合before_send做字段白名单裁剪
为什么 try/except 里吞掉异常后 Sentry 还收到了？
因为 Sentry 默认捕获所有未处理异常（sys.excepthook），但一旦你写了 except 并没重新抛出，它就收不到——除非你主动调 sentry_sdk.capture_exception()。
这个点最容易被忽略：很多团队以为“只要 init 了 Sentry 就自动抓所有异常”，结果发现手动 except 后的错误全漏报。
- 吞异常时务必补一句：
sentry_sdk.capture_exception(e) - 不要只写
capture_message("failed")—— 它不带栈，查不出根因 - 如果用
logging.exception()，可配LoggingIntegration(event_level=logging.ERROR)自动转成 Sentry 事件，但前提是 logger 没被其他 handler 吞掉
线上环境变量混杂、异步逻辑穿插、异常捕获层级不统一——这些才是让错误排查变慢的真正瓶颈，而不是 SDK 本身配置多难。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
