速记engineeringfrontendcaching

静态资源缓存破坏:?v= 与长哈希怎么选

发版后用户仍看到旧 CSS/JS,多半是缓存策略问题;用版本查询或内容哈希对齐。

约 773 字 · 2 分钟读完

背景

纯静态站依赖 CDN 与浏览器缓存。资源文件若沿用同一 URL,边缘节点可能长时间返回旧文件。工程上常见两种破坏方式:查询参数版本号(如 ?v=47)与文件名内容哈希(app.a1b2c3.css)。

对个人站与小团队而言,把这类实践写进构建与规则文件,比事后救火便宜。0xKEV 提供浏览器本地工具,方便在不上传的前提下先辨认样本、再决定是否交给自动化。

要点

  1. 同一路径改内容必须换指纹:否则只能靠短 TTL 或 purge。
  2. HTML 入口不该被长期缓存:首页指向最新指纹。
  3. 大文件用不可变缓存:指纹 URL 可设一年。
  4. 发版后按需 purge:只清 HTML 与关键路径,减少全站失效成本。

另外记住:可验证优于「感觉好了」。能量化的用命令与指标;不能量化的至少留下检查清单与复盘记录。

怎么做

  1. 构建脚本统一注入 ASSET_V 或写哈希清单。
  2. 发版检查:打开首页源码确认 CSS/JS 版本号已跳。
  3. 用无痕窗口与强制刷新各验一次。
  4. 记录 purge 范围,避免误清整站。

建议把上述步骤收成团队检查项或 CI 门禁。首次落地选一个痛点场景试点,跑通后再横向复制,避免一次性铺开导致无人维护。

辨认现状 → 写清目标与非目标 → 小步改 → 验证 → 文档化

和本站工具

用本站 哈希 核对产物;HTTP 状态 理解缓存相关码;Diff 对比发版前后引用。

入口:Tools 首页(本地运算、免注册)。隐私说明见 隐私。处理生产样例前请先脱敏。

版本号方案实现简单,适合个人站;内容哈希更适合大型构建链。关键是「入口永远指向新指纹」。

落地时把「谁负责、何时复查」写清楚,避免清单成为墙上标语。可用日历提醒做季度回顾,删除过时步骤,补充新的失败案例。与本站其他速记交叉阅读,能把部署、安全与成本视角连成一张实践图。

实践上建议建立「最小可重复检查」:每次改动后用同一组命令或同一份清单验证,把结果贴进变更说明。这样后来者不必猜测你当时是否测过。若涉及自动化,先在预发或本地复现,再放到生产路径;失败时保留现场(日志、配置摘要、版本号),方便复盘而不是只留下一句「修好了」。与安全相关的步骤务必默认拒绝、显式允许;与成本相关的步骤务必带预算与度量。0xKEV 速记栏只记录可核实的工程事实,方便检索与内链,不替代你团队自己的 Runbook。

小结

本文只讨论可执行的工程做法。把边界、验证与文档当作一等公民,工具与自动化才能真正省时间,而不是放大事故面。

← 全部速记