走代理线路的业务，为了让排查有据可依，往往会把请求体一起记进日志。这个习惯本身没问题，问题出在记的时候没有挑拣。一段登录请求里往往带着账号和口令，一份提交表单里可能带着联系方式，这些内容一旦原样落盘，日志就从排障工具变成了风险点。
脱敏要解决的是同一个矛盾：既要保留足够定位问题的信息，又不能把敏感内容原样留下。做法是按字段性质分类处理：该遮的遮住，该留的留着。
- 身份凭据类
- 口令、令牌一类整段替换，不保留任何字符
- 联系信息类
- 保留字段名与前几位，其余用固定符号遮盖
- 业务数值类
- 可以完整保留，它们通常不涉及个人
- 自由文本类
- 按长度上限截断，避免夹带未预期的内容
哪些字段必须脱敏
口令、会话令牌、密钥这几类没有商量余地，一旦落盘就等同于泄露，哪怕日志访问权限控制得很严。联系方式和身份号码这一类需要保留部分信息，做法通常是留头留尾，中间用固定符号替代，既能核对是不是同一个值，又看不出完整内容。业务数值一般可以直接保留，订单号、金额这类信息对排查有价值，本身也不涉及个人。
脱敏的判据是这条信息落盘之后会不会带来麻烦。把这一条当作唯一标准，遇到拿不准的字段时就容易做决定了。
代理侧能看到多少
经代理转发的明文流量里，请求体在链路上是可读的，这也是为什么明文场景下更要控制日志范围。加密流量里，请求体在通道内传输，中间环节拿不到内容，日志里也就不会有这一部分。把两种场景分开看，能避免在不可能的地方做无用功。
需要提醒的是，脱敏要在写入之前做。先落盘再清理，中间那段时间里内容已经存在过，事后清理也补不回这段窗口。
脱敏规则应当写成清单并固定下来，靠每次人工判断迟早会漏。
记住一条：代理日志是给排障用的，不是给留档用的。按这个定位去决定记什么、遮什么，尺度就清楚了。