长缓存策略与文件哈希

性能优化 长缓存策略与文件哈希

长缓存策略是提升应用加载速度的关键手段之一，结合文件哈希能有效解决缓存更新问题。Vite.js 通过内置机制实现了这一优化方案，开发者只需简单配置即可获得显著性能提升。

长缓存策略的核心原理

浏览器缓存分为强缓存和协商缓存两种机制。长缓存策略主要利用强缓存，通过设置较长的 Cache-Control max-age 时间（如一年），让静态资源在客户端长期有效。这种策略能显著减少重复请求，但面临一个关键问题：如何在不影响缓存命中率的情况下更新文件？

文件哈希完美解决了这个矛盾点。Vite 会在构建时为每个文件生成唯一哈希值，并附加到文件名中（如 main.abc123.js）。当文件内容变化时，哈希值随之改变，浏览器会将其视为全新资源请求。而未修改的文件则继续保持缓存状态。

Vite 中的哈希配置实践

Vite 默认使用基于文件内容的哈希算法，在 vite.config.js 中可以通过 build.rollupOptions 进行深度定制：

// vite.config.js
export default {
  build: {
    rollupOptions: {
      output: {
        // 配置哈希格式
        assetFileNames: 'assets/[name]-[hash][extname]',
        chunkFileNames: '[name]-[hash].js',
        entryFileNames: '[name]-[hash].js'
      }
    }
  }
}

哈希策略有三种主要模式：

1. [hash]：基于整个构建过程生成
2. [chunkhash]：基于 chunk 内容生成
3. [contenthash]：基于文件内容生成（CSS 文件推荐）

哈希算法选择与性能权衡

Vite 4 开始默认使用 xxhash64 算法，相比传统的 md5 和 sha-256 有显著性能优势：

# 不同哈希算法性能对比（处理 1GB 数据）
md5: 450ms
sha256: 600ms 
xxhash64: 120ms

虽然 xxhash64 不是加密安全哈希，但前端资源哈希仅用于版本控制而非安全场景，这种取舍完全合理。如需加密哈希，可通过配置更换：

import { createHash } from 'node:crypto'

export default {
  build: {
    rollupOptions: {
      plugins: [{
        name: 'custom-hash',
        generateBundle(_, bundle) {
          for (const file in bundle) {
            const chunk = bundle[file]
            if (chunk.type === 'asset') {
              chunk.fileName = chunk.fileName.replace(
                /\[hash\]/,
                createHash('sha256').update(chunk.source).digest('hex').slice(0, 8)
              )
            }
          }
        }
      }]
    }
  }
}

缓存控制头部的正确设置

仅配置文件哈希还不够，必须配合正确的 HTTP 缓存头才能发挥最大效果。在生产环境中应这样配置：

location /assets {
  # 设置一年强缓存
  expires 1y;
  add_header Cache-Control "public, immutable";
  
  # 启用协商缓存验证
  etag on;
  if_modified_since exact;
}

关键点在于 immutable 属性的使用，它告诉浏览器在缓存有效期内不需要再发送验证请求（如 If-None-Match），进一步减少网络往返。实测表明，这能使缓存命中率提升 15-20%。

解决哈希变化的依赖追踪问题

当使用 [chunkhash] 时，模块间的依赖关系可能导致不必要的哈希变化。例如：

// utils.js
export function sharedUtil() {
  console.log('v1')
}

// a.js
import { sharedUtil } from './utils'
console.log('module A')

// b.js  
import { sharedUtil } from './utils' 
console.log('module B')

如果只修改 a.js，理想情况下 b.js 的哈希不应变化。Vite 通过以下方式优化：

1. 将第三方依赖提取到单独 chunk（vendor）
2. 使用稳定模块 ID 替代数字 ID
3. 通过 manualChunks 手动控制分块

// vite.config.js
export default {
  build: {
    rollupOptions: {
      output: {
        manualChunks(id) {
          if (id.includes('node_modules')) {
            return 'vendor'
          }
        }
      }
    }
  }
}

动态导入的哈希处理技巧

动态导入的模块需要特殊处理以保证缓存一致性。考虑这个路由组件懒加载场景：

// 原始写法 - 可能导致哈希不一致
const About = () => import('../../views/About.vue')

优化方案是使用明确的静态字符串：

// 改进写法 - 保证稳定的 chunk 划分
const About = () => import(/* webpackChunkName: "about" */ './views/About.vue')

在 Vite 中，还可以通过 build.modulePreload 配置预加载策略：

export default {
  build: {
    modulePreload: {
      polyfill: false,
      resolveDependencies: (url, deps, context) => {
        return deps.filter(/* 自定义过滤逻辑 */)
      }
    }
  }
}

哈希策略的调试与分析

使用 vite-plugin-visualizer 可以直观分析哈希效果：

npm install --save-dev vite-plugin-visualizer

配置插件：

import { visualizer } from 'vite-plugin-visualizer'

export default {
  plugins: [
    visualizer({
      open: true,
      gzipSize: true,
      brotliSize: true
    })
  ]
}

构建后会生成图表显示：

• 各 chunk 的大小占比
• 哈希分布情况
• 重复依赖分析
• Gzip/Brotli 压缩效果

服务端渲染(SSR)的特殊处理

SSR 场景下需要特别注意模块哈希的一致性。常见问题包括：

• 客户端与服务器构建结果不一致
• 开发环境与生产环境哈希算法差异
• 动态导入导致的 hydration 不匹配

解决方案是在 SSR 构建时固定模块 ID：

export default {
  ssr: {
    noExternal: ['react', 'react-dom'],
    format: 'cjs',
    target: 'node',
    rollupOptions: {
      output: {
        hoistTransitiveImports: false,
        inlineDynamicImports: false,
        preserveModules: true
      }
    }
  }
}

哈希与 CDN 的协同优化

当使用 CDN 时，需要调整哈希策略以适应多级缓存：

1. 配置 CDN 边缘节点缓存规则
2. 设置合适的 Cache-Control 头部
3. 实现快速回源验证

示例阿里云 CDN 配置：

{
  "CacheConfig": {
    "IgnoreCacheControl": false,
    "TTL": 31536000,
    "CacheContent": ["/assets/"],
    "Compress": true
  },
  "OriginProtocol": "follow",
  "Http2": true
}

同时需要在 Vite 中配置对应的 base 路径：

export default {
  base: 'https://cdn.example.com/assets/'
}

版本文件的高效管理

随着项目迭代，可能积累大量带哈希的旧文件。推荐通过 build.clean 配置自动清理：

export default {
  build: {
    clean: true,
    emptyOutDir: true
  }
}

对于需要保留多个版本的特殊场景，可以自定义清理逻辑：

import fs from 'fs'
import path from 'path'

const keepLastVersions = 3

export default {
  plugins: [{
    closeBundle() {
      const assetsDir = path.resolve('dist/assets')
      const files = fs.readdirSync(assetsDir)
      
      // 按修改时间排序并保留最新三个版本
      const sorted = files
        .map(file => ({ file, mtime: fs.statSync(path.join(assetsDir, file)).mtime }))
        .sort((a, b) => b.mtime - a.mtime)
      
      sorted.slice(keepLastVersions).forEach(({ file }) => {
        fs.unlinkSync(path.join(assetsDir, file))
      })
    }
  }]
}

哈希策略的异常处理

某些边缘情况可能导致哈希失效，需要特别注意：

1. 时间戳问题：构建机器时钟不同步导致虚假哈希变化

   • 解决方案：使用 process.env.SOURCE_DATE_EPOCH 固定时间戳

2. 环境变量注入：不同环境构建产生不同哈希

   // 错误做法
   const env = process.env.NODE_ENV
   
   // 正确做法 - 通过 define 固定
   export default {
     define: {
       __APP_ENV__: JSON.stringify('production')
     }
   }
   

3. 内容相同但哈希不同：换行符等不可见字符差异

   • 解决方案：构建时统一换行符

   export default {
     esbuild: {
       charset: 'utf8',
       lineEndings: 'unix'
     }
   }
   

性能监控与调优指标

实施长缓存策略后，应监控以下核心指标：

1. 缓存命中率：通过 Service Worker 或 CDN 日志分析

   // sw.js 示例统计
   self.addEventListener('fetch', event => {
     const cached = caches.match(event.request)
     if (cached) {
       reportAnalytics('cache-hit')
     }
   })
   

2. 资源加载时间分布：使用 Navigation Timing API

   const [entry] = performance.getEntriesByType('navigation')
   console.log('DNS:', entry.domainLookupEnd - entry.domainLookupStart)
   console.log('TCP:', entry.connectEnd - entry.connectStart)
   

3. 更新效率：计算哈希变更率

   # 对比两次构建的哈希变化
   diff <(ls dist/assets/*.js | grep -oE '[a-f0-9]{8}') <(ls prev-dist/assets/*.js | grep -oE '[a-f0-9]{8}')