HSTS的max-age应匹配HTTPS成熟度与运维能力，生产环境推荐63072000秒（2年）；启用includeSubDomains需确保所有子域支持HTTPS；撤销策略唯一方式是返回max-age=0并持续HTTPS响应。
HSTS 的 max-age 不是越大越安全，也不是越小越灵活——它本质是一个“信任时长承诺”，设得过长，出问题难回退；设得太短，起不到实质防护。关键在于匹配网站的 HTTPS 成熟度和运维保障能力。
生产环境推荐：63072000 秒（2 年）为基准值
这是当前主流平台（Google、GitHub、Cloudflare 等）普遍采用的数值，对应 2 年有效期。它足够长，能覆盖绝大多数用户会话周期，让浏览器长期记住“只走 HTTPS”，有效抵御协议降级、SSL剥离等中间人攻击。
- 必须确保全站及所有子域名已稳定运行 HTTPS 至少 3 个月以上，且无混合内容（HTTP 资源加载）问题
- 需具备自动证书续签能力（如 ACME + Let’s Encrypt），避免因证书过期导致整个域名不可访问
- 若启用
preload，max-age 至少需为 31536000 秒（1 年），且必须同时带includeSubDomains
上线前验证阶段：用 300–86400 秒过渡
刚完成 HTTPS 全量切换或准备提交预加载列表时，切忌一步到位设 2 年。建议先以 5 分钟（300 秒）或 1 天（86400 秒）部署，观察真实流量下的行为：
- 检查浏览器是否正确收到 Strict-Transport-Security 响应头（开发者工具 → Network → Headers）
- 确认 HTTP 请求是否被自动重写为 HTTPS（尤其测试直接输入
http://example.com） - 排查子域名是否因未配 HTTPS 而变白屏（若已加
includeSubDomains） - 验证 CDN、反向代理、WAF 等中间层是否透传或正确注入该 Header
includeSubDomains 的启用前提很实际
加上这个参数不难，难的是它把安全责任扩展到了每一个子域名——mail.example.com、dev.example.com、甚至临时测试用的 pr-123.example.com 都必须能响应 HTTPS 请求。
- 若存在任一子域暂不支持 HTTPS，宁可不加该参数，改用显式配置各子域独立 HSTS
- 内部管理后台、监控页、健康检查端点等常被忽略的子域，也要纳入 HTTPS 覆盖范围
- 使用通配符证书时，注意其是否覆盖所有计划启用 HSTS 的子域名
撤销与降级：max-age=0 是唯一可靠退出方式
一旦 HSTS 生效，浏览器不会因服务器停发 Header 而自动取消策略——只能等 max-age 过期，或用户手动清除浏览数据。因此：
- 紧急情况下需快速解除 HSTS（如证书故障、HTTPS 配置错误），唯一办法是返回
Strict-Transport-Security: max-age=0，并确保该响应本身通过 HTTPS 发出 - max-age=0 必须持续返回至少 max-age 原值的时间长度，才能让所有已缓存策略的客户端逐步失效
- 已提交到浏览器预加载列表的域名，无法通过 max-age=0 撤销，只能等待官方列表更新周期（通常数周至数月）
