生产环境日志中必须脱敏Traceback里的文件绝对路径、函数参数值、局部变量（如password/token）、自定义异常消息等敏感上下文；应优先遍历结构化traceback对象清洗，而非字符串替换，并覆盖所有异常逃逸路径。

Python 错误堆栈里哪些信息必须脱敏

生产环境日志里的 Traceback 不能直接暴露路径、变量值、函数参数，尤其是含用户数据或密钥的地方。比如 File "/home/deploy/app/user_service.py" 暴露部署路径，password='123456' 出现在局部变量打印里，都是高危点。

真正要脱敏的不是“错误类型”，而是堆栈中所有可能携带敏感上下文的字符串字段：文件绝对路径、函数调用时的具体参数值、局部变量快照（locals()）、甚至自定义异常消息里的原始输入。

• traceback.format_exception() 返回的每行文本都要过一遍清洗，不能只处理 exc_info[2] 的 frame 对象
• 不要依赖正则全局替换 password=.*? —— 容易漏掉键名变形（如 pwd、api_key）或嵌套结构中的值
• 异常消息本身（str(exc)）常被忽略，但它可能直接拼接了用户邮箱、手机号等，必须单独处理

用 traceback.walk_tb() + 自定义 tb_next 遍历更可控

直接操作 sys.exc_info() 得到的 traceback 对象，比用 format_exc() 字符串再切分更可靠。因为前者保留了结构化帧信息，能精准定位每个 co_filename、f_locals，避免文本解析错位。

关键不是“格式化后再脱敏”，而是“在遍历帧时就过滤内容”。例如：

import traceback
import sys
def scrubbed_traceback(exc_type, exc_value, tb):
for frame, lineno in traceback.walk_tb(tb):
脱敏文件路径
    filename = frame.f_code.co_filename
    frame.f_code.co_filename = "<redacted>" if filename.startswith("/home/") else filename
    # 清空敏感 locals，但保留非敏感键（如计数器、状态码）
    if "password" in frame.f_locals:
        frame.f_locals["password"] = "<hidden>"
    if "token" in frame.f_locals:
        frame.f_locals["token"] = "<hidden>"
return traceback.format_exception(exc_type, exc_value, tb)

注意：frame.f_code.co_filename 是只读属性，上面示例是示意逻辑；实际需用 types.FrameType 替换或改用 traceback.print_exception() 的 handler 方式。

• 不要修改 frame.f_locals 原地值 —— CPython 下它可能被优化掉，且某些 frame（如内置函数）不提供该属性
• 优先用 traceback.print_exception() 的 file 参数配合 StringIO 捕获输出，再逐行清洗，比改 frame 更稳定
• co_filename 在 PyInstaller 或 zipimport 场景下可能是 ，这类不用脱敏，但需识别跳过

第三方库如 loguru 或 structlog 的脱敏钩子怎么配

loguru 没有内置堆栈脱敏，得靠 patch() 注入自定义异常处理器；structlog 则依赖 exception_formatter 中间件。两者都不支持开箱即用的字段级擦除，必须自己写清洗逻辑。

以 loguru 为例，常见错误是只重写了 record["exception"] 的文本，却没动 record["extra"] 里可能存的原始 sys.exc_info()：

import loguru
def scrub_exception(record):
exc = record["exception"]
if exc is not None:
这里必须重新生成 format_exception，不能只 replace 字符串
    tb_lines = traceback.format_exception(*exc)
    cleaned = [line.replace("/var/www/", "[PATH]") for line in tb_lines]
    record["exception"] = (exc.type, exc.value, "".join(cleaned))
logger = loguru.logger.patch(scrub_exception)

• structlog 的 ExceptionRenderer 默认不处理 f_locals，需继承并重写 _render_exception() 方法
• 所有方案都绕不开对 traceback.format_exception() 输出的再加工 —— 没有“自动识别敏感变量”的银弹
• 如果用了 Sentry 或 Datadog，它们的 SDK 会提前序列化堆栈，此时脱敏必须在 before_send 钩子里做，且要深拷贝 event dict，否则影响上报

为什么不能只靠日志级别或环境变量开关来控制脱敏

有人把脱敏逻辑包进 if os.getenv("ENV") == "prod"，结果测试环境堆栈照样打满路径和参数，上线才意识到没生效。根本问题是：脱敏不是“要不要打日志”，而是“打了什么内容”。只要日志最终落盘或上报，就必须确保内容已清洗。

更麻烦的是异步场景：Celery 任务、FastAPI 后台任务、线程池里的异常，容易漏掉全局异常钩子（sys.excepthook），导致部分堆栈根本没走脱敏流程。

• sys.excepthook 只捕获主线程未处理异常，子线程需单独设 threading.excepthook（Python 3.8+）
• ASGI 应用（如 FastAPI）的异常中间件只管 HTTP 层，后台任务里的 asyncio.create_task() 抛异常，得靠 asyncio.get_event_loop().set_exception_handler()
• 最稳妥的方式是：所有日志输出前统一走一个 scrub_traceback_text() 函数，不管来源是 print、logger 还是 Sentry，避免分散治理

脱敏真正难的不是写几行正则，而是覆盖所有异常逃逸路径 —— 从同步代码、协程、子进程，到信号处理、atexit 回调，只要可能产生 traceback，就得确认它是否经过清洗。漏掉任意一条链路，敏感信息就可能出现在不该出现的地方。