Sentry在Django生产环境收不到错误，90%因SDK初始化位置错、LOGGING未路由或DEBUG=True未关；须在wsgi.py顶层初始化、设environment、启用LoggingIntegration、手动捕获404/403、禁用send_default_pii并用before_send脱敏。
Sentry 在 Django 生产环境收不到错误，90% 是因为 SDK 初始化位置错、LOGGING 没路由、或 DEBUG=True 没关——不是 DSN 写错了。
SDK 必须在 wsgi.py/asgi.py 顶层初始化，不能放 settings.py
放在 settings.py 会导致每次 Django 加载配置（比如运行 manage.py check 或 Celery worker 启动）都调一次 sentry_sdk.init()。Gunicorn 多 worker 部署下会创建多个 Sentry 客户端，引发连接泄漏、事件丢失甚至内存暴涨。
实操建议：
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 在
wsgi.py中，application = get_wsgi_application()之后、return application之前插入初始化代码 - 加个简单防护：用
if not sentry_sdk.Hub.current.client:判断是否已初始化，避免重复调用 - 必须传
environment="production"（或"staging"），否则所有事件都归到production环境，无法区分
LOGGING 配置不路由到 Sentry，logging.error() 就不会上报
Sentry SDK 默认只捕获未处理异常（如视图里直接 raise ValueError），但业务中大量使用 logger.error() 或 logger.exception() 记录问题——这些日志默认被 Django 的 LOGGING 配置拦住，根本不会进 Sentry。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 安装时必须用
pip install sentry-sdk[integrations]，不是纯sentry-sdk - 初始化时显式传入
LoggingIntegration(event_level=logging.ERROR, level=logging.ERROR) - 确认
LOGGING配置中，root或djangologger 的handlers包含sentry（Sentry SDK 会自动注册该 handler） - 测试方法：在视图里写
import logging; logging.error("test log")，看 Sentry 是否收到
404、403 这类 HTTP 错误默认不触发 Sentry，需手动捕获
Django 把 Http404 当作正常流程处理，不抛异常；PermissionDenied 被中间件转成 403 响应后也不再冒泡。这两类错误不会触发 SDK 的异常捕获机制。
实操建议：
- 在
urls.py末尾定义handler404 = "myapp.views.custom_404"，并在该视图中调用sentry_sdk.capture_message(f"404 on {request.path}", level="warning") - 对
PermissionDenied，在自定义中间件的process_exception中捕获，但要加判断：if isinstance(exc, PermissionDenied) and not hasattr(request, '_sentry_403_handled'):，避免和 Django 自带 403 处理逻辑冲突 - 不要全局
raise Http404替代 404 响应——这会破坏缓存、SEO 和中间件顺序
敏感数据没过滤，DSN 泄露+日志含密码=生产事故
send_default_pii=True 会让 Sentry 自动提取 request.POST、request.GET、request.META 里的所有字段，包括 password、api_key、Authorization 头、数据库连接串等。这些一旦上传，就不可撤回。
实操建议：
- 生产环境必须设
send_default_pii=False - 用
before_send回调做精准脱敏：before_send=lambda event, hint: None if "password" in str(event) else event（更稳妥的是遍历event.get("request", {}).get("data", {})） - 检查 DSN 是否混用：Sentry 控制台每个项目有独立 DSN，
@后的项目 ID 必须匹配，且不能被环境变量（如SENTRY_DSN）意外覆盖 - 上线前务必确认
DEBUG=False且ALLOWED_HOSTS已设——否则 500 错误可能被 Django 中间件外层拦截，根本到不了 Sentry
最常被跳过的一步是验证 LOGGING 路由和 before_send 过滤逻辑是否真正生效。别只看“有没有报错”，要查 Sentry 事件详情页的 request.data 和 logentry 字段是否干净——这才是线上监控真正落地的分水岭。
