Spring Controller GET REST API被第三方服务认证用户访问时多次调用的问题排查

Hey there, let's break down why your GET endpoint is returning concatenated invalid JSON (three repeated payloads) while the POST version works fine. Here are actionable troubleshooting steps to pinpoint the root cause:

1. Verify JWT Filter Invocation Frequency #

Since you have a JWT token filter configured, it’s possible this filter is being triggered multiple times for GET requests—leading to repeated response writes. Add detailed logging in your filter’s doFilter method to track each invocation:

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
    HttpServletRequest req = (HttpServletRequest) request;
    String logMsg = String.format("Filter hit: Method=%s, URI=%s, Thread ID=%d", 
                                 req.getMethod(), req.getRequestURI(), Thread.currentThread().getId());
    System.out.println(logMsg); // Or use a logger like SLF4J
    chain.doFilter(request, response);
}

• If logs show the same GET request being filtered three times, check your filter registration: Did you register it via both @WebFilter and FilterRegistrationBean? Or is there a duplicate entry in your Spring config that’s adding the filter multiple times to the chain?

2. Inspect Direct Response Writing in GET Endpoint #

Compare your GET and POST endpoint implementations. The GET version uses HttpServletResponse as a parameter—are you manually writing to the response stream (e.g., response.getWriter().write(json)) without properly handling the response lifecycle?

• If you’re directly writing to the response output stream multiple times (either in the controller or filter), that’s likely causing the concatenated JSON. The POST version uses @RequestBody and relies on Spring’s default message converters to handle response serialization, which avoids manual stream writes and accidental duplicates.
• Check if your filter is also writing content to the response, which would stack with the controller’s output.

3. Rule Out Duplicate Requests (Client/Proxy Side) #

Even though Postman reproduces the issue, confirm if three distinct requests are being sent, or if one request is being processed three times. Add logging at the start of your controller method to track unique request identifiers:

public ResponseEntity getResult(HttpServletRequest request, HttpServletResponse response, @RequestParam Long id) {
    String requestId = request.getHeader("X-Request-ID");
    if (requestId == null) requestId = UUID.randomUUID().toString();
    System.out.println("Processing request ID: " + requestId + " | Method: GET");
    // Rest of your code
}

• If you see three different request IDs, the problem lies with the client (ServiceB’s Flutter frontend) or an intermediate proxy/gateway that’s retrying GET requests. Check for frontend issues like missing debouncing, or proxy settings that auto-retry on perceived "failed" responses.

4. Check Spring MVC Content Negotiation & Message Converters #

Misconfigured content negotiation or custom message converters can cause unexpected response duplication.

• Review your Spring config for custom HttpMessageConverter beans—are they overriding default behavior and accidentally writing the response multiple times?
• Check if content negotiation is enabled for multiple media types (e.g., JSON + XML) and if the GET request’s Accept header is triggering multiple conversion attempts.

5. Debug the Request Lifecycle Step-by-Step #

Fire up your IDE’s debugger and set breakpoints at:

• The entry of your JWT filter
• The start of your GET controller method
• Any line where you write to the HttpServletResponse stream
• The end of the filter chain (chain.doFilter(...) call)

By stepping through the code, you can see exactly when the response is being written multiple times, and whether it’s the same request being reprocessed or multiple requests coming in.

内容的提问来源于stack exchange，提问作者user14132461