报错只记一句异常信息，无法知道对应哪个请求。日志设计要围绕排查链路，而不是尽可能多打印对象。
本文使用Java Web 小项目的演示工程与协作场景。初入团队时，重要的不只是写出功能，还包括让别人能够复现、审查和接手。本文使用匿名任务说明工作方法，不指代某家公司的内部流程或真实交付成绩。
1. 从现象推到机制
入口生成关联编号，向服务调用和异常处理传递，记录阶段、耗时与结果类别。业务编号和技术请求编号解决不同问题；同一业务重试可能对应多次请求。敏感参数不应因为调试方便进入日志。
图中的四个节点分别表示请求入口、调用过程、结果记录、上下文清理。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
先在过滤器中建立上下文，并在 finally 清理线程局部状态，避免容器线程复用后串到下一个请求。下面为流程示意。
1
2
3
4
5
6
7
request_id = new_id()
try:
attach_context(request_id)
process_request()
finally:
record_duration_and_status()
clear_context()
示例命令需要在独立演示工程中执行，路径和服务均由读者准备。操作前保留当前版本与输入，修改后对照原来的问题验证，而不是只证明新代码能够编译。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 同一订单连续重试 | 业务号相同但请求号不同 |
| 线程池复用处理下一请求 | 不能带上上一请求上下文 |
| 异常中包含敏感参数 | 应保留类别并脱敏细节 |
对照 1：同一订单连续重试
业务号相同但请求号不同。观察时记录两类身份的关联关系。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：线程池复用处理下一请求
不能带上上一请求上下文。观察时记录finally 清理是否执行。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：异常中包含敏感参数
应保留类别并脱敏细节。观察时记录最终日志的实际内容。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
日志本身也有容量和访问成本。先定义保留周期、级别和检索字段，再决定采集范围，避免调试输出挤满磁盘。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“异常中包含敏感参数”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
