报错是这么冒出来的。CloudFront 的 behavior 只配了 default TTL 86400，源站没给 Cache-Control。发布后首页和列表页一天内都是旧的，蜘蛛上午抓完就不再回来，新文第二天才进索引。
中间走过弯路，把「没配 invalidation，发布流程只重启了应用」当成主因，改完现象没变。
这类报错背后常见的原因有几处，逐个排除就行。Default TTL 覆盖了源站缺失的缓存头。少数情况下是behavior 的 path pattern 把 HTML 全包进长缓存。
还有一种情况，Minimum TTL 把源站较短的 max-age 抬高了。
上来先看响应头实际 TTL
curl -sI https://www.example.com/ | grep -iE 'cache-control|x-cache'调低 HTML 的 default TTL
aws cloudfront update-distribution --distribution-config file://cf.json发布后主动失效
aws cloudfront create-invalidation --distribution-id $DIST --paths '/*'等前面都确认过，再让源站输出短缓存头
add_header Cache-Control 'public, max-age=60, s-maxage=60';那几天正好在做别的变更，先把时间线对齐才敢动手。
怎么算真的好了，看的是同一批现象。首页 max-age 降到 60 秒，发布后失效一分钟内生效，新文当天被抓取。
提醒一点。HTML 和静态资源的缓存策略要分开，把 24 小时套在页面上，等于让蜘蛛每天只看到一次新内容。这类问题最好一次改到位，反复小改反而容易把原因搅混。