生产环境日志中必须脱敏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，避免文本解析错位。
关键不是“格式化后再脱敏”，而是“在遍历帧时就过滤内容”。例如：
立即学习“Python免费学习笔记（深入）”；
import traceback
import sys
<p>def scrubbed_traceback(exc_type, exc_value, tb):
for frame, lineno in traceback.walk_tb(tb):</p><h1>脱敏文件路径</h1><pre class='brush:python;toolbar:false;'> 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 场景下可能是<frozen xxx></frozen>，这类不用脱敏，但需识别跳过
第三方库如 loguru 或 structlog 的脱敏钩子怎么配
loguru 没有内置堆栈脱敏，得靠 patch() 注入自定义异常处理器；structlog 则依赖 exception_formatter 中间件。两者都不支持开箱即用的字段级擦除，必须自己写清洗逻辑。
以 loguru 为例，常见错误是只重写了 record["exception"] 的文本，却没动 record["extra"] 里可能存的原始 sys.exc_info()：
import loguru
<p>def scrub_exception(record):
exc = record["exception"]
if exc is not None:</p><h1>这里必须重新生成 format_exception，不能只 replace 字符串</h1><pre class='brush:python;toolbar:false;'> 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，就得确认它是否经过清洗。漏掉任意一条链路，敏感信息就可能出现在不该出现的地方。
