看起来你遇到的情况挺棘手的——明明代码里配置了HSTS的max-age，结果响应头里始终是max-age=0，甚至默认状态下也是这个值。结合你提到的其他HTTP配置正常、断点看到自己的配置调用了方法的情况，我整理了几个可能的原因和调试思路，你可以一步步排查：

一、先检查配置文件是否覆盖了代码设置 #

Spring Boot的配置文件（application.properties/application.yml）里的相关属性会优先于Java代码配置。你可以检查有没有以下配置：

# 全局服务器级别的HSTS配置
server.http-strict-transport-security.max-age=0
# 或者Spring Security专属的HSTS配置
spring.security.headers.hsts.max-age=0
spring.security.headers.hsts.enabled=true

如果存在这类配置，会直接覆盖你在WebSecurityConfig里的设置，导致max-age被强制设为0。

二、排查是否有其他过滤器修改响应头 #

有可能存在自定义过滤器或者第三方库的过滤器，在Spring Security写入HSTS头之后，又修改了这个值。你可以添加一个简单的日志过滤器，在所有过滤器执行完后打印最终的响应头：

@Component
public class HstsHeaderCheckerFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        // 先执行后续所有过滤器
        filterChain.doFilter(request, response);
        // 打印最终的HSTS头信息
        String hstsValue = response.getHeader("strict-transport-security");
        System.out.printf("请求URL: %s | 最终HSTS响应头: %s%n", request.getRequestURL(), hstsValue);
    }
}

如果打印结果还是max-age=0，说明问题出在Spring Security内部或前置环节；如果中间有值的变化，就能定位到是哪个过滤器修改了头。

三、调试Spring Security的最终头写入逻辑 #

Spring Security是通过HstsHeaderWriter类来写入HSTS头的，你可以在这个类的核心方法上打个断点，看看最终生效的配置值：

1. 找到org.springframework.security.web.header.writers.HstsHeaderWriter类
2. 在writeHeaders(HttpServletRequest request, HttpServletResponse response)方法处断点
3. 查看this.configuration.maxAge的值——如果这里就是0，说明你的配置没有正确传递到最终的写入器；如果这里是你设置的31536000，那说明是后续环节被修改了。

四、检查是否有多个Security配置类冲突 #

如果你的项目里有多个WebSecurityConfigurerAdapter的实现类，优先级低的配置会被优先级高的覆盖。你可以给当前的WebSecurityConfig加上@Order(1)注解，确保它的优先级最高：

@Configuration
@EnableWebSecurity
@Order(1) // 确保这个配置最先被加载，避免被其他配置覆盖
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
    // 你的配置代码...
}

五、尝试替换配置方法写法 #

试试用maxAge(Duration)方法替代maxAgeInSeconds，虽然底层逻辑一致，但有时候参数传递的小细节可能导致意外：

http.headers().httpStrictTransportSecurity()
    .maxAge(Duration.ofDays(365))
    .includeSubDomains(true);

看看修改后响应头的max-age是否正常。

如果以上步骤都没解决问题，你还可以额外检查：

• 应用是否处于特殊环境（比如测试环境），有没有环境相关的条件注解（如@Profile）影响了配置生效？
• 有没有误调用过http.headers().disable()或者http.headers().httpStrictTransportSecurity().disable()，之后又重新启用？虽然你说代码里没有，但可以再仔细确认下。

内容的提问来源于stack exchange，提问作者Bjørn Vårdal