curl -sI https://api.example.com/v1/posts/88 | grep -i last-modified stat -c '%y' /data/posts/88.md
文章改完立刻刷新接口，返回的还是 304，前端拿着缓存里的旧标题。响应头里的 Last-Modified 和上次一模一样，时间是 10:00:00。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：Last-Modified 只精确到秒，同一秒内的两次修改时间戳相同，服务端按 If-Modified-Since 比较时认为资源没变。文件系统的时间精度、序列化时截掉毫秒，都会让两次修改撞进同一秒里。
这次卡住的地方就在「Last-Modified 精度」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
处理上按这个顺序：把 Last-Modified 换成 ETag 用响应体摘要做校验；确实要保留时间校验 就把修改时间存到毫秒并在比较时带上；发布后主动刷新缓存 别等客户端下次协商；把同一秒内连续修改的场景写进测试用例 每次发版跑一遍。
确认没问题再收工，同一秒内改两次 第二次请求返回 200 和新内容 不再出现 304。