CDN的Last-Modified头是浏览器缓存验证的核心机制，正确配置能显著减少回源请求，降低服务器负载并提升用户访问速度。
在Web性能优化的日常实践中,很多站长容易陷入一个误区：认为只要上了CDN，网站就自动变快了，事实并非如此，CDN的本质是边缘节点的分发网络，而Last-Modified作为HTTP响应头之一，负责告诉客户端资源最后修改的时间，如果这个时间戳配置不当，要么导致用户看到过期的旧内容，要么因为频繁验证而增加不必要的网络开销，理解并正确设置Last-Modified，是打通CDN加速最后一公里的钥匙。
Last-Modified与ETag的缓存博弈
为什么需要缓存验证机制
浏览器缓存分为强缓存和协商缓存,强缓存通过Cache-Control或Expires决定资源是否直接从本地读取，期间不与服务器通信，一旦强缓存失效，浏览器就会发起条件请求，这时Last-Modified就登场了，它携带一个时间戳发送给服务器，服务器对比该时间与资源实际修改时间，若未变则返回304状态码，告知浏览器继续使用本地缓存；若变了则返回200及新资源。
业内专家指出,合理的缓存策略能节省约40%以上的带宽流量，对于静态资源如图片、CSS、JS文件，Last-Modified配合ETag（实体标签）使用效果最佳，ETag基于文件内容哈希生成，精度高于时间戳，但计算开销较大，多数情况下，建议对大文件使用ETag，对小文件使用Last-Modified，以平衡性能与准确性。
Last-Modified的局限性
尽管Last-Modified广泛使用，但它存在几个天然缺陷，首先是精度问题，HTTP头的时间戳精度通常只能到秒，如果文件在秒级内多次修改，Last-Modified无法察觉，导致缓存不更新，其次是时区问题，不同服务器时区设置不一致可能导致时间戳偏差，某些文件系统（如NFS）在复制文件时可能保留原文件的修改时间，造成Last-Modified不准确。
针对这些痛点,行业共识认为，现代CDN服务商通常会在边缘节点自动处理Last-Modified的生成和验证逻辑，屏蔽底层文件系统的差异，但对于自建源站或混合云架构，仍需手动检查源站Header配置，确保时间戳真实反映内容变更。
CDN场景下的Last-Modified实战配置
源站Header的正确设置
要让CDN正确传递Last-Modified，源站必须首先输出正确的Header，以Nginx为例，默认配置下，Nginx会自动根据文件修改时间设置Last-Modified，但如果你使用了动态生成页面或缓存插件，可能需要手动干预。
在Nginx配置中,可以通过以下指令确保Header正确传递：
location ~ .(jpg|jpeg|png|gif|ico|css|js)$ {
expires 30d;
add_header Cache-Control "public, no-transform";
# 确保Last-Modified不被忽略
if_modified_since exact;
}
对于Apache服务器,需确保FileETag和ModExpires模块启用，并检查.htaccess中是否有覆盖配置的指令，关键点是，源站输出的Last-Modified必须是UTC时间，且与文件实际inode修改时间一致。
CDN控制台缓存规则设置
不同CDN厂商对Last-Modified的处理逻辑略有差异，但核心原则一致：优先使用源站Header，若源站缺失则生成默认值，在阿里云、腾讯云或Cloudflare等主流平台，你可以在控制台设置缓存过期时间。
操作路径如下：
- 登录CDN控制台,进入“缓存配置”或“缓存规则”页面。
- 选择“按扩展名设置缓存”或“按目录设置缓存”。
- 针对静态资源（如.css, .js, .png），设置较长的缓存时间，如7天或30天。
- 确保勾选“忽略源站Cache-Control”或“优先使用源站Header”选项，具体取决于你的业务需求，若源站配置严谨，建议优先使用源站Header，以保证一致性。
值得注意的是,部分CDN支持“缓存键”自定义，你可以将URL参数纳入缓存键，避免不同参数请求共用同一缓存版本，从而防止Last-Modified验证失效。
版本化与伪静态的冲突解决
在前端工程中,常通过文件名哈希（如app.a1b2c3.js）实现版本控制，这种情况下，文件一旦生成，内容永不改变，Last-Modified也固定不变，CDN可以安全地长期缓存，但若使用伪静态或动态路由，URL不变而内容变化，Last-Modified将成为唯一验证依据。
需在源站代码中动态生成准确的Last-Modified时间戳，在PHP中可使用filemtime()函数，在Node.js中使用fs.statSync().mtime，确保每次内容更新时，时间戳严格递增，避免回退，否则可能导致浏览器缓存混乱。
常见问题与排查指南
Last-Modified不生效怎么办
若发现浏览器未发送If-Modified-Since请求，或服务器未返回304，首先检查浏览器开发者工具的“Network”面板，查看响应头中是否包含Last-Modified，以及请求头中是否包含If-Modified-Since。
若源站未输出Last-Modified，检查Web服务器配置是否被重写规则拦截，若CDN未缓存，检查缓存命中率统计，确认请求是否直达源站，多数情况下，问题出在CDN缓存规则过于严格，或源站Header被错误覆盖。
时间不同步导致缓存失效
当源站与CDN节点时间不同步时,Last-Modified可能出现未来时间戳，导致浏览器认为资源未过期，从而拒绝更新，解决方法是统一服务器NTP时间同步，并在CDN控制台开启“时间戳校验”功能（若支持），对于跨国业务，建议使用UTC时间，并在应用层统一转换。
Last-Modified优化最佳实践
结合Cache-Control使用
Last-Modified并非孤立存在，应与Cache-Control协同工作，对于极少变动的静态资源，设置长时效的Cache-Control（如1年），并配合Last-Modified进行验证，这样，浏览器在有效期内直接读取本地文件，仅在过期后发起轻量级验证，大幅降低网络请求数。
监控与日志分析
定期分析CDN访问日志,关注304状态码的比例，若304比例过低，说明缓存验证频繁，可能Last-Modified配置不当或缓存时间过短，若304比例过高但用户反馈内容未更新，则需检查时间戳生成逻辑是否准确。
据工信部相关数据显示,优化HTTP缓存策略可使静态资源加载时间缩短30%以上，通过精细调控Last-Modified和ETag，不仅能提升用户体验，还能显著降低源站带宽成本。
Q&A：Last-Modified常见疑问解答
CDN Last-Modified与ETag哪个优先级更高？
HTTP/1.1规范规定，若同时存在ETag和Last-Modified，服务器应优先使用ETag进行验证，因为ETag基于内容哈希，精度更高，但在实际CDN应用中，若ETag生成开销过大，可禁用ETag，仅保留Last-Modified，多数现代CDN默认启用两者，以提供最佳兼容性。
如何测试Last-Modified是否生效？
使用浏览器开发者工具,打开“Network”面板，刷新页面，首次加载查看响应头中的Last-Modified字段，再次刷新，若资源未修改，应看到请求头中包含If-Modified-Since，且响应状态码为304，若返回200，则说明缓存未命中或Last-Modified未正确传递。
动态页面是否适用Last-Modified？
频繁变化，通常不建议使用长期缓存，若必须缓存，需确保Last-Modified精确反映内容更新时间，并设置较短的缓存时长（如秒级或分钟级），对于API接口，更推荐使用ETag或自定义缓存策略，以避免Last-Modified精度不足带来的问题。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/cdn-last-modified%e4%b8%ba%e4%bd%95%e5%a4%b1%e6%95%88%ef%bc%9f%e5%a6%82%e4%bd%95%e9%85%8d%e7%bd%ae%e7%bc%93%e5%ad%98%e5%91%bd%e4%b8%ad/
评论列表（1条）
笑死，以为上了CDN就自动快？大错特错！Last-Modified要是配不好，缓存全白搭。