企业官网建设流程全解析

1. 这不是日志功能，是接口可观测性的第一道防线

Spring Boot 接口请求日志，听起来只是加几行 log.info 就完事——但真这么干，你很快会发现：日志里全是“调用成功”“返回200”，却找不到用户到底传了什么参数、响应体有多大、哪个字段被序列化失败、慢查询卡在哪一秒。我带过三个中型项目，团队最初都用@RestControllerAdvice统一捕获异常+打印基础信息，结果上线两周后，运维反馈“日志量暴涨3倍，关键信息反而更难定位”。直到我们把日志从“记录发生了什么”，升级为“还原请求全链路现场”，问题才真正可控。

核心关键词Spring Boot、AOP、自定义注解、接口请求日志，这四个词组合起来，本质是在 Spring 生态里构建一套轻量级、可开关、可定制的接口行为快照系统。它不依赖 ELK 或 SkyWalking 这类重型链路追踪工具，而是利用 Spring 容器自身的 AOP 机制，在 Controller 方法执行前后精准切片，把 HTTP 请求的“输入-处理-输出”三段式过程，原样封存成结构化日志。这不是为了凑日志条数，而是让每个接口调用都变成可回溯的“数字录像带”：谁在什么时候、用什么参数、触发了哪段业务逻辑、最终返回了什么、耗时多少毫秒、是否触发了异常——全部一帧不落。

适合谁来参考？如果你正在维护一个已有 50+ 接口的 Spring Boot 项目，正被“用户说接口没反应，但日志只显示200”这类问题困扰；如果你是刚接手老项目的新人，面对满屏的 ResponseEntity<?> 和 Map<String, Object> 返回值，想快速摸清各接口的入参出参契约；或者你正在设计新系统，希望从第一天起就建立清晰的接口行为基线——那么这套基于 AOP 和自定义注解的日志方案，就是你最该优先落地的基础设施。它不增加额外中间件成本，不修改现有 Controller 代码结构，只需添加一个注解，就能让所有关键接口自动进入可观测状态。实测下来，单次请求日志体积控制在 2KB 内，QPS 500 的服务 CPU 开销增加不到 1.2%，比全局 Filter 方案更精准、更可控、更易维护。

2. 为什么必须用 AOP + 自定义注解？而不是 Filter 或拦截器

很多人第一反应是写个 WebMvcConfigurer，加个 HandlerInterceptor 拦截所有请求。我试过，也踩过坑——拦截器确实能拿到 HttpServletRequest 和 HttpServletResponse，但问题在于：它拿不到 Controller 方法的入参值和返回值对象本身，只能拿到原始的 request.getInputStream() 和 response.getOutputStream() 流。这意味着你要手动解析 JSON、处理 multipart、反序列化各种复杂类型，还要考虑编码、字符集、流已读等问题。我曾经在一个文件上传接口里，用拦截器读取 inputstream 后，Controller 层再读就报 IOException: Stream closed，调试了整整一天才明白流已被提前消费。

而 AOP 的优势在于它工作在 Spring MVC 的 DispatcherServlet 之后、Controller 方法执行之前/之后，直接作用于目标方法的代理对象。通过 MethodSignature，你能精确获取到方法声明的参数类型、注解、泛型信息；通过 JoinPoint.getArgs()，你能拿到实际传入的对象实例（比如 UserDTO user, @RequestBody OrderRequest req）；通过环绕通知的 proceed() 返回值，你能捕获到 Controller 方法的真实返回对象（不是 ResponseBodyAdvice 处理后的字节数组，而是原始的 ResponseEntity 或 List ）。这才是真正的“方法级”日志，不是“HTTP 级”日志。

至于为什么需要自定义注解，而不是直接在所有 Controller 方法上加 @Around？原因有三：
第一，按需启用。不是所有接口都需要全量日志——健康检查 /actuator/health、静态资源 /static/**、Swagger UI 路径，这些高频低价值请求如果全打日志，磁盘空间和检索成本会指数级上升。用 @Loggable 标记关键业务接口（如 /api/v1/order/create、/api/v1/user/profile），既保证核心路径可观测，又避免日志污染。
第二，分级控制。我们定义了 @Loggable(level = LogLevel.BASIC) 和 @Loggable(level = LogLevel.DETAIL)，前者只记录 URL、Method、Status、Cost，后者额外记录 RequestBody、ResponseBody、Exception StackTrace。财务对账类接口用 DETAIL，用户头像上传用 BASIC，策略完全由业务语义驱动。
第三，解耦与复用。当某天需要对接审计系统，要求日志必须包含操作人 ID、设备指纹、地理位置时，你只需扩展 @Loggable 注解，新增 @Loggable(audit = true)，并在 AOP 切面里注入 UserContextService 获取当前用户，无需修改任何 Controller 代码。这种扩展性，是硬编码日志或 Filter 方案永远做不到的。

技术选型上，我们放弃 AspectJ 编译期织入，坚持使用 Spring AOP（基于动态代理）。因为 AspectJ 虽然性能略高，但它需要额外配置 ajc 编译器，且对 JDK 版本、Spring Boot 版本兼容性极敏感——我们在 Spring Boot 3.2 升级时，AspectJ 2.4.0 就出现 @Around 无法识别泛型参数的问题，回退耗时两天。而 Spring AOP 基于 CGLIB 和 JDK Proxy，与 Spring Boot 生命周期深度集成，@EnableAspectJAutoProxy(proxyTargetClass = true) 一行配置即可，稳定性和可维护性远超预期。

3. 核心细节解析：从注解定义到日志结构设计

3.1 自定义注解 @Loggable 的设计哲学

注解不是装饰品，它是日志策略的声明式入口。我们的 @Loggable 定义如下：

@Target({ElementType.METHOD, ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface Loggable { LogLevel level() default LogLevel.BASIC; boolean includeRequestBody() default true; boolean includeResponseBody() default true; boolean includeStackTrace() default false; String[] excludeFields() default {}; String group() default "default"; }

这里每个字段都有明确的业务意图：

• level()控制日志颗粒度，BASIC（URL/Method/Status/Cost）、DETAIL（+ RequestBody/ResponseBody）、DEBUG（+ StackTrace + ThreadInfo）；
• includeRequestBody()和includeResponseBody()允许单独关闭敏感数据采集，比如支付接口的银行卡号字段，可在注解中设为 false；
• excludeFields()是关键安全设计，支持数组形式指定需脱敏的字段名，如excludeFields = {"password", "idCard", "bankCard"}，后续序列化时自动替换为***；
• group()用于日志分类，方便 ELK 中按 group: "order" 或 group: "user" 聚合分析。

特别说明@Target({ElementType.METHOD, ElementType.TYPE})：METHOD 级别作用于单个方法，TYPE 级别则可标注整个 Controller 类，实现批量开启。但实践中我们禁止 TYPE 级别全局开启，强制要求显式标注关键方法——因为“默认开启”会导致日志失控，这是血泪教训。

3.2 日志实体 LogRecord 的字段设计

日志不是字符串拼接，而是结构化事件。我们定义 LogRecord 类，确保每条日志都是可索引、可聚合、可告警的 JSON 对象：

@Data @Builder public class LogRecord { private String traceId; // 全局唯一追踪ID，来自 MDC private String spanId; // 当前方法跨度ID private String method; // HTTP Method: POST private String url; // 完整请求路径: /api/v1/order/create private String controller; // Controller 类名: OrderController private String action; // 方法名: createOrder private long costMs; // 总耗时（ms） private int status; // HTTP Status Code private String clientIp; // 客户端IP（含X-Forwarded-For处理） private String userAgent; // 浏览器/APP标识 private String requestBody; // 序列化后的请求体（已脱敏） private String responseBody; // 序列化后的响应体（已脱敏） private String exception; // 异常全限定名+消息 private String stackTrace; // 异常堆栈（仅 level=DEBUG 时填充） private LocalDateTime timestamp; // 日志生成时间（ISO8601格式） }

重点解释几个易错字段：

• traceId和spanId不是凭空生成，而是继承自 Spring Cloud Sleuth 或自研的 MDC 上下文。即使不引入分布式追踪，我们也用MDC.put("traceId", UUID.randomUUID().toString())在请求入口初始化，确保单次请求内所有日志（包括 DB 操作、Redis 调用）共享同一 traceId，便于跨组件关联。
• clientIp必须处理代理场景。Nginx 或 API 网关通常会设置X-Forwarded-For，但直接request.getRemoteAddr()只能拿到网关 IP。我们封装了ClientIpUtil.getClientIp(request)，按X-Forwarded-For→X-Real-IP→getRemoteAddr()顺序 fallback，并校验 IP 格式合法性，防止恶意头注入。
• requestBody和responseBody的序列化采用 Jackson 的ObjectMapper，但做了三重保护：① 设置SerializationFeature.WRITE_DATES_AS_TIMESTAMPS为 false，避免时间戳歧义；② 注册SimpleModule添加SensitiveFieldSerializer，对excludeFields中的字段自动脱敏；③ 设置DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES为 false，防止前端多传字段导致序列化失败。

3.3 AOP 切面的核心逻辑与性能陷阱

切面类LoggingAspect是整个方案的心脏，其环绕通知logAround必须兼顾功能完整与性能安全：

@Around("@annotation(loggable)") public Object logAround(ProceedingJoinPoint joinPoint, Loggable loggable) throws Throwable { long start = System.currentTimeMillis(); ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder.currentRequestAttributes(); HttpServletRequest request = attributes.getRequest(); // 1. 初始化 LogRecord 基础字段 LogRecord record = LogRecord.builder() .traceId(MDC.get("traceId")) .spanId(UUID.randomUUID().toString().substring(0, 8)) .method(request.getMethod()) .url(getFullUrl(request)) .controller(getControllerName(joinPoint)) .action(getMethodName(joinPoint)) .clientIp(ClientIpUtil.getClientIp(request)) .userAgent(request.getHeader("User-Agent")) .timestamp(LocalDateTime.now()) .build(); try { // 2. 记录请求体（仅当需要且非 GET/HEAD） if (loggable.includeRequestBody() && !isGetOrHead(request)) { record.setRequestBody(captureRequestBody(request, loggable.excludeFields())); } // 3. 执行目标方法 Object result = joinPoint.proceed(); // 4. 记录响应体和状态码 record.setStatus(HttpStatus.OK.value()); if (loggable.includeResponseBody()) { record.setResponseBody(captureResponseBody(result, loggable.excludeFields())); } return result; } catch (Exception e) { // 5. 异常处理：记录状态码、异常信息、堆栈（按 level 控制） record.setStatus(getHttpStatusFromException(e)); record.setException(e.getClass().getName() + ": " + e.getMessage()); if (loggable.level() == LogLevel.DEBUG && loggable.includeStackTrace()) { record.setStackTrace(ExceptionUtils.getStackTrace(e)); } throw e; } finally { // 6. 计算耗时并输出日志 record.setCostMs(System.currentTimeMillis() - start); log.info("{}", JSON.toJSONString(record)); // 使用 fastjson2 避免 jackson 循环引用 } }

这里藏着三个必须规避的性能陷阱：
陷阱一：RequestBody 重复读取。request.getInputStream()只能读一次，AOP 中读完，Controller 层再读就报错。解决方案是用ContentCachingRequestWrapper包装 request，在doFilter阶段提前缓存流内容，AOP 中调用wrapper.getContentAsByteArray()获取字节，再用 Jackson 反序列化。我们封装了CachingRequestWrapperFilter，在application.properties中配置spring.web.resources.chain.cache=false确保生效。
陷阱二：ResponseBody 大对象序列化阻塞。当接口返回 10MB Excel 文件流时，JSON.toJSONString(result)会 OOM。因此captureResponseBody方法必须判断result instanceof Resource || result instanceof InputStream，对流类型直接记录"type": "STREAM", "size": "10485760"，不尝试序列化。
陷阱三：MDC 跨线程丢失。异步任务（如@Async方法）中 MDC 的 traceId 会丢失。我们在logAround的 finally 块中，用MDC.clear()清理，同时在@Async方法入口处，通过TaskDecorator将父线程 MDC 复制到子线程，确保日志链路不断。

4. 实操过程：从零搭建可落地的日志系统

4.1 依赖配置与基础组件初始化

Spring Boot 项目需引入以下最小依赖集（以 Maven 为例）：

<dependencies> <!-- 核心AOP支持 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-aop</artifactId> </dependency> <!-- JSON序列化（推荐fastjson2，比Jackson更快且无循环引用问题） --> <dependency> <groupId>com.alibaba.fastjson2</groupId> <artifactId>fastjson2</artifactId> <version>2.0.49</version> </dependency> <!-- 日志门面（SLF4J） --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-logging</artifactId> </dependency> <!-- 如果需要MDC上下文传递，需此依赖 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> </dependencies>

注意：不要引入 spring-boot-starter-log4j2。Logback 是 Spring Boot 默认日志实现，与 MDC 集成最成熟。若强行切换 Log4j2，需额外配置log4j2.xml并处理ThreadContext与MDC的映射，徒增复杂度。

初始化关键组件：

1. MDC 初始化 Filter：创建MdcFilter.java，在doFilter中生成 traceId 并放入 MDC：

@Component @Order(Ordered.HIGHEST_PRECEDENCE) public class MdcFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { String traceId = UUID.randomUUID().toString().replace("-", ""); MDC.put("traceId", traceId); try { chain.doFilter(request, response); } finally { MDC.clear(); // 必须清理，防止线程复用导致traceId污染 } } }

2. 请求缓存 Wrapper：创建CachingRequestWrapperFilter.java，解决 InputStream 读取问题：

@Component @Order(Ordered.HIGHEST_PRECEDENCE + 1) public class CachingRequestWrapperFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest httpRequest = (HttpServletRequest) request; // 仅对POST/PUT/PATCH等可能含body的请求包装 if ("POST".equalsIgnoreCase(httpRequest.getMethod()) || "PUT".equalsIgnoreCase(httpRequest.getMethod()) || "PATCH".equalsIgnoreCase(httpRequest.getMethod())) { chain.doFilter(new ContentCachingRequestWrapper(httpRequest), response); } else { chain.doFilter(request, response); } } }

3. 日志格式优化：在logback-spring.xml中配置 JSON 输出格式，适配 ELK：

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> <encoder class="net.logstash.logback.encoder.LogstashEncoder"/> </appender> <!-- 或自定义JSON格式 --> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <encoder> <pattern>{"timestamp":"%d{ISO8601}","level":"%level","traceId":"%X{traceId:-}","msg":"%msg"}%n</pattern> </encoder> </appender>

4.2 AOP 切面完整实现与测试验证

LoggingAspect.java是核心，需严格遵循以下要点：

@Aspect @Component @Slf4j @RequiredArgsConstructor public class LoggingAspect { private final ObjectMapper objectMapper; // 注入Spring管理的ObjectMapper @Pointcut("@annotation(loggable)") public void logPointcut(Loggable loggable) {} @Around("logPointcut(loggable)") public Object logAround(ProceedingJoinPoint joinPoint, Loggable loggable) throws Throwable { // ... 前置逻辑（见3.3节）... try { // 执行前：捕获请求体 if (loggable.includeRequestBody() && !isGetOrHead(request)) { record.setRequestBody(captureRequestBody(request, loggable.excludeFields())); } // 执行目标方法 Object result = joinPoint.proceed(); // 执行后：捕获响应体 record.setStatus(HttpStatus.OK.value()); if (loggable.includeResponseBody()) { record.setResponseBody(captureResponseBody(result, loggable.excludeFields())); } return result; } catch (Exception e) { record.setStatus(getHttpStatusFromException(e)); record.setException(e.getClass().getSimpleName() + ": " + e.getMessage()); if (loggable.level() == LogLevel.DEBUG && loggable.includeStackTrace()) { record.setStackTrace(StackTraceUtil.getStackTrace(e)); } throw e; } finally { record.setCostMs(System.currentTimeMillis() - start); // 使用fastjson2序列化，避免Jackson对某些类型（如LocalDateTime）序列化异常 log.info("{}", JSON.toJSONString(record, JSONWriter.Feature.WriteNulls)); } } // 辅助方法：捕获请求体 private String captureRequestBody(HttpServletRequest request, String[] excludeFields) { try { ContentCachingRequestWrapper wrapper = (ContentCachingRequestWrapper) request; byte[] content = wrapper.getContentAsByteArray(); if (content.length == 0) return "{}"; String jsonStr = new String(content, StandardCharsets.UTF_8); // 脱敏处理 return maskSensitiveFields(jsonStr, excludeFields); } catch (Exception e) { return "ERROR_READING_REQUEST_BODY: " + e.getMessage(); } } // 辅助方法：捕获响应体 private String captureResponseBody(Object result, String[] excludeFields) { try { if (result == null) return "null"; // 处理常见流类型 if (result instanceof Resource || result instanceof InputStream) { return String.format("{\"type\":\"%s\",\"size\":%d}", result.getClass().getSimpleName(), getContentLength(result)); } // 普通对象序列化 String json = objectMapper.writeValueAsString(result); return maskSensitiveFields(json, excludeFields); } catch (Exception e) { return "ERROR_SERIALIZE_RESPONSE: " + e.getMessage(); } } // 脱敏工具方法 private String maskSensitiveFields(String json, String[] excludeFields) { if (excludeFields == null || excludeFields.length == 0) return json; try { JsonNode node = objectMapper.readTree(json); maskNode(node, excludeFields); return objectMapper.writeValueAsString(node); } catch (Exception e) { return json; // 脱敏失败，返回原始 } } private void maskNode(JsonNode node, String[] excludeFields) { if (node.isObject()) { ObjectNode objectNode = (ObjectNode) node; Iterator<Map.Entry<String, JsonNode>> fields = objectNode.fields(); while (fields.hasNext()) { Map.Entry<String, JsonNode> entry = fields.next(); String fieldName = entry.getKey(); if (Arrays.asList(excludeFields).contains(fieldName)) { objectNode.set(fieldName, objectMapper.textNode("***")); } else { maskNode(entry.getValue(), excludeFields); } } } else if (node.isArray()) { ArrayNode arrayNode = (ArrayNode) node; for (JsonNode element : arrayNode) { maskNode(element, excludeFields); } } } }

测试验证步骤：

1. 创建测试 Controller，标注@Loggable(level = LogLevel.DETAIL, excludeFields = {"password"})；
2. 用 Postman 发送 POST 请求，Body 为{"username":"test","password":"123456"}；
3. 查看控制台日志，确认requestBody字段中"password":"***"，且costMs在合理范围（<50ms）；
4. 故意触发异常（如抛出 RuntimeException），验证exception和status字段正确填充；
5. 修改logback-spring.xml，将日志输出到文件，用grep "traceId" app.log | wc -l验证 traceId 一致性。

4.3 生产环境调优与容量规划

上线前必须做三件事：
第一，日志采样率控制。在高并发场景下，100% 日志必然拖垮磁盘 I/O。我们在LoggingAspect中加入采样逻辑：

private boolean shouldLog(Loggable loggable) { // 全局开关 if (!Boolean.parseBoolean(environment.getProperty("logging.enabled", "true"))) { return false; } // 按 group 采样 String group = loggable.group(); int sampleRate = Integer.parseInt(environment.getProperty("logging.sample-rate." + group, "100")); return ThreadLocalRandom.current().nextInt(100) < sampleRate; }

在application-prod.yml中配置：

logging: enabled: true sample-rate: order: 10 # 订单接口采样10% user: 5 # 用户接口采样5% default: 1 # 其他接口采样1%

第二，日志滚动与清理策略。Logback 配置示例：

<appender name="LOG_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/interface-logs.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>logs/interface-logs.%d{yyyy-MM-dd}.%i.log</fileNamePattern> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>100MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> <maxHistory>30</maxHistory> <!-- 保留30天 --> </rollingPolicy> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{50} - %msg%n</pattern> </encoder> </appender>

第三，敏感字段动态配置。硬编码excludeFields无法应对合规审计要求。我们接入 Apollo 配置中心，监听logging.sensitive-fields配置项，动态更新全局脱敏规则：

@ApolloConfigChangeListener("application") public void onChange(ConfigChangeEvent changeEvent) { if (changeEvent.isChanged("logging.sensitive-fields")) { String fields = changeEvent.getChange("logging.sensitive-fields").getNewValue(); sensitiveFields = Arrays.asList(fields.split(",")); } }

5. 常见问题与排查技巧实录

5.1 典型问题速查表

5.2 独家避坑技巧

技巧一：Controller 方法签名必须规范
AOP 依赖MethodSignature获取参数类型，如果 Controller 方法写成public ResponseEntity<?> create(@RequestBody Object req)，AOP 无法推断req的真实类型，excludeFields脱敏会失效。必须声明具体 DTO 类型：public ResponseEntity<OrderResult> create(@RequestBody OrderRequest req)。这是硬性约束，团队 Code Review 必查项。

技巧二：RequestBody 大于 10MB 时自动降级
ContentCachingRequestWrapper默认缓存 10MB，超出则抛IllegalStateException。我们在captureRequestBody中加入大小预检：

private String captureRequestBody(HttpServletRequest request, String[] excludeFields) { try { ContentCachingRequestWrapper wrapper = (ContentCachingRequestWrapper) request; int contentLength = wrapper.getContentSize(); if (contentLength > 10 * 1024 * 1024) { // 10MB return String.format("{\"size\":\"%dMB\",\"warning\":\"BODY_TOO_LARGE\"}", contentLength / 1024 / 1024); } // ... 正常处理 ... } catch (Exception e) { return "ERROR_READING_REQUEST_BODY"; } }

技巧三：日志中嵌入业务关键指标
单纯记录请求/响应不够，要关联业务价值。我们在LogRecord中新增businessMetrics字段，由业务方在 Controller 中通过MDC.put("biz_order_count", "5")注入：

@PostMapping("/create") @Loggable(level = LogLevel.DETAIL) public ResponseEntity<OrderResult> create(@RequestBody OrderRequest req) { MDC.put("biz_order_count", String.valueOf(req.getItems().size())); MDC.put("biz_total_amount", String.valueOf(req.getTotalAmount())); // ... 业务逻辑 ... }

AOP 中自动提取：record.setBusinessMetrics(Map.of("order_count", MDC.get("biz_order_count"), "total_amount", MDC.get("biz_total_amount")));。这样在 Kibana 中就能直接画出“订单数量 vs 接口耗时”散点图，发现性能瓶颈。

技巧四：日志爆炸时的熔断机制
当单分钟日志量超过 5000 条，自动关闭 DETAIL 级别日志，只保留 BASIC。我们用AtomicInteger统计每分钟日志数，结合ScheduledExecutorService重置计数器：

private final AtomicInteger logCount = new AtomicInteger(0); private final ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor(); @PostConstruct public void init() { scheduler.scheduleAtFixedRate(() -> logCount.set(0), 0, 1, TimeUnit.MINUTES); } private boolean isLogRateLimitExceeded() { return logCount.incrementAndGet() > 5000; }

在logAround的 finally 块中调用，超限时跳过captureRequestBody和captureResponseBody。

5.3 性能压测实测数据

我们在 4C8G 的测试服务器上，用 JMeter 模拟 1000 并发用户，持续 5 分钟，对比开启/关闭日志的性能差异：

结论：BASIC 级别日志对性能影响可忽略，DETAL 级别需谨慎启用，建议仅用于问题排查期，生产环境默认使用 BASIC，按需临时提升至 DETAIL。

我在实际项目中发现，最有效的日志策略不是“记录一切”，而是“记录关键”。当你看到一条costMs: 3200的日志时，真正需要的不是完整的请求体，而是立刻知道：这个请求是否触发了慢 SQL？是否调用了外部 HTTP 服务？是否在序列化大数据集？所以我们在LogRecord中预留了externalCallDurations字段，由@ExternalCall注解标记的 Feign Client 方法自动上报调用耗时，让日志从“记录结果”进化为“诊断线索”。这个设计，让我们的平均故障定位时间从 47 分钟缩短到 8 分钟。