前端日志回捞系统的性能优化实践｜得物技术

得

沸腾2025年09月08日约 8 分钟

一、前言

二、核心性能优化

1. 优化一：智能化数据库清理机制

2. 优化二：上传模块的异步加载架构

3. 优化三：JSZip 库的动态引入

4. 优化四：日志队列与性能优化

三、打包构建中的技术难点与解决方案

1. 难点一：异步加载 import() 打包失败问题

2. 难点二：process 对象未定义问题

3. 难点三：第三方依赖的 ESM/CJS 兼容性问题

四、性能测试与效果对比

五、总结

一

前言

在现代前端应用中，日志回捞系统是排查线上问题的重要工具。然而，传统的日志系统往往面临着包体积过大、存储无限膨胀、性能影响用户体验等问题。本文将深入分析我们在@dw/log和@dw/log-upload两个库中实施的关键性能优化，以及改造过程中遇到的技术难点和解决方案。

核心优化策略概览：

我们的优化策略主要围绕三个核心问题：

存储膨胀问题 - 通过智能清理策略控制本地存储大小
包体积问题 - 通过异步模块加载实现按需引入
性能影响问题 - 通过队列机制和节流策略提升用户体验

二

核心性能优化

优化一：智能化数据库清理机制

问题背景

传统日志系统的一个重大痛点是本地存储无限膨胀。用户长期使用后，IndexedDB 可能积累数万条日志记录，不仅占用大量存储空间，更拖慢了所有数据库查询和写入操作。

解决方案：双重清理策略

我们实现了一个智能清理机制，它结合了两种策略，并只在浏览器空闲时执行，避免影响正常业务。

双重清理：

按时间清理：删除N天前的所有日志。
按数量清理：当日志总数超过阈值时，删除最旧的日志，直到数量达标。

/** * 综合清理日志（同时处理过期和数量限制） * @param retentionDays 保留天数 * @param maxLogCount 最大日志条数 */async cleanupLogs(retentionDays?: number, maxLogCount?: number): Promise<void> {  if (!this.db) {    throw new Error('Database not initialized')  }  try {    // 先清理过期日志    if (retentionDays && retentionDays > 0) {      await this.clearExpiredLogs(retentionDays)    }    // 再清理超出数量限制的日志    if (maxLogCount && maxLogCount > 0) {      await this.clearExcessLogs(maxLogCount)    }  } catch (error) {    // 日志清理失败不应该影响主流程    console.warn('日志清理失败:', error)  }}

智能调度：

节流：保证清理操作在短时间内（如5分钟）最多执行一次。
空闲执行：将清理任务调度到浏览器主线程空闲时执行，确保不与用户交互或页面渲染争抢资源。

/** * 检查并执行清理（节流版本，避免频繁清理） */private checkAndCleanup = (() => {  let lastCleanup = 0  const CLEANUP_INTERVAL = 5 * 60 * 1000 // 5分钟最多清理一次  return () => {    const now = Date.now()    if (now - lastCleanup > CLEANUP_INTERVAL) {      lastCleanup = now      executeWhenIdle(() => {        this.performCleanup()      }, 1000)    }  }})()

优化二：上传模块的异步加载架构

问题背景

日志上传功能涉及 OSS 上传、文件压缩等重型依赖，如果全部打包到主库中，会显著增加包体积。更重要的是，大部分用户可能永远不会触发日志上传功能。

解决方案：动态模块加载

189KB 的包体积是不可接受的。分析发现，包含文件压缩（JSZip）和OSS上传的 @dw/log-upload模块是体积元凶，但99%的用户在正常浏览时根本用不到它。

我们采取了“核心功能+插件化”的设计思路，将非核心的上传功能彻底分离。

上传模块分离：将上传逻辑拆分为独立的@dw/log-upload库，并通过CDN托管。
动态加载实现：仅在用户手动触发“上传日志”时，才通过动态创建script标签的方式，从CDN异步加载上传模块。我们设计了一个单例加载器确保模块只被请求一次。

/** * OSS 上传模块的远程 URL */const OSS_UPLOADER_URL = 'https://cdn-jumper.dewu.com/sdk-linker/dw-log-upload.js'
/** * 动态加载远程模块 * 使用单例模式确保模块只加载一次 */const loadRemoteModule = async (): Promise<LogUploadModule> => {  if (!moduleLoadPromise) {    moduleLoadPromise = (async () => {      try {        await loadScript(OSS_UPLOADER_URL)        return window.DWLogUpload      } catch (error) {        moduleLoadPromise = null        throw error      }    })()  }  return moduleLoadPromise}
/** * 上传文件到 OSS */export const uploadToOss = async (file: File, curEnv?: string, appId?: string): Promise<string> => {  try {    // 懒加载上传函数    if (!ossUploader) {      const module = await loadRemoteModule()      ossUploader = module.uploadToOss    }    const result = await ossUploader(file, curEnv, appId)    return result  } catch (error) {    console.info('Failed to upload file to OSS:', error)    return ''  }}

优化三：JSZip库的动态引入

我们避免将 JSZip 打包到主库中，从主包中移除，改为在上传模块内部动态引入，优先使用业务侧可能已加载的全局window.JSZip。

/** * 获取 JSZip 实例 */export const getJSZip = async (): Promise<JSZip | null> => {  try {    if (!JSZipCreator) {      const module = await loadRemoteModule()      JSZipCreator = module.JSZipCreator    }    zipInstance = new window.JSZip()    return zipInstance  } catch (error) {    console.info('Failed to create JSZip instance:', error)    return null  }}
// 在上传模块中实现灵活的 JSZip 加载export const JSZipCreator = async () => {  // 优先使用全局 JSZip（如果页面已经加载了）  if (window.JSZip) {    return window.JSZip  }  return JSZip}

优化四：日志队列与性能优化

在某些异常场景下，日志会短时间内高频触发（如循环错误），密集的IndexedDB.put()操作会阻塞主线程，导致页面卡顿。

我们引入了一个日志队列，将所有日志写入请求“缓冲”起来，再由队列控制器进行优化处理。

限流：设置每秒最多处理的日志条数（如50条），超出部分直接丢弃。错误（Error）级别的日志拥有最高优先级，不受此限制，确保关键信息不丢失。
批处理与空闲执行：将队列中的日志打包成批次，利用requestIdleCallback在浏览器空闲时一次性写入数据库，极大减少了 I/O 次数和对主线程的占用。

export class LogQueue {  private readonly MAX_LOGS_PER_SECOND = 50  /**   * 检查限流逻辑   */  private checkRateLimit(entry: LogEntry): boolean {    // 错误日志总是被接受    if (entry.level === 'error') {      return true    }    const now = Date.now()    if (now - this.lastResetTime > 1000) {      this.logCount = 0      this.lastResetTime = now    }    if (this.logCount >= this.MAX_LOGS_PER_SECOND) {      return false    }    this.logCount++    return true  }}

空闲时间处理机制：

export function executeWhenIdle(callback: () => void, timeout: number = 2000): void {  if (typeof window !== 'undefined' && 'requestIdleCallback' in window) {    window.requestIdleCallback(() => {      callback()    }, { timeout })  } else {    setTimeout(callback, 50)  }}

三

打包构建中的技术难点

与解决方案

在改造过程中，我们遇到了许多与打包构建相关的技术难题。这些问题往往隐藏较深，但一旦出现就会阻塞整个开发流程。以下是我们遇到的主要问题和解决方案：

难点一：异步加载 import()

打包失败问题

问题描述

await import('./module')语法在 Rollup 打包为 UMD 格式时会直接报错，因为 UMD 规范本身不支持代码分割。

// 这样的代码会导致 UMD 打包失败const loadModule = async () => {  const module = await import('./upload-module')  return module}

错误信息：

Error: Dynamic imports are not supported in UMD builds[!] (plugin commonjs) RollupError: "import" is not exported by "empty.js"

解决方案：inlineDynamicImports 配置

通过在 Rollup 配置中设置inlineDynamicImports: true来解决这个问题：

// rollup.config.jsexport default {  input: 'src/index.ts',  output: [    {      file: 'dist/umd/dw-log.js',      format: 'umd',      name: 'DwLog',      // 关键配置：内联动态导入      inlineDynamicImports: true,    },    {      file: 'dist/cjs/index.js',      format: 'cjs',      // CJS 格式也需要这个配置      inlineDynamicImports: true,    }  ],  plugins: [    typescript(),    resolve({ browser: true }),    commonjs(),  ]}

配置说明

inlineDynamicImports: true会将所有动态导入的模块内联到主包中
这解决了 UMD 格式不支持动态导入的问题

难点二：process对象未定义问题

问题描述

打包后的代码在浏览器环境中运行时出现process is not defined错误：

ReferenceError: process is not defined    at Object.<anonymous> (dw-log.umd.js:1234:56)

这通常是因为某些 Node.js 模块或工具库在代码中引用了process对象，而浏览器环境中并不存在。

解决方案：插件注入 process 对象

我们使用@rollup/plugin-inject插件，在打包时向代码中注入一个模拟的process 对象，以满足这些库的运行时需求。

创建process-shim.js文件提供浏览器端的process实现。
在rollup.config.js中配置插件：

// rollup.config.jsimport inject from '@rollup/plugin-inject'import path from 'path'
export default {  // ... 其他配置  plugins: [    // 注入 process 对象    inject({      // 使用文件导入方式注入 process 对象      process: path.join(__dirname, 'process-shim.js'),    }),    typescript(),    resolve({ browser: true }),    commonjs(),  ]}

创建 process-shim.js 文件：

// process-shim.js// 为浏览器环境提供 process 对象的基本实现export default {  env: {    NODE_ENV: 'production'  },  browser: true,  version: '',  versions: {},  platform: 'browser',  argv: [],  cwd: function() { return '/' },  nextTick: function(fn) {    setTimeout(fn, 0)  }}

高级解决方案：条件注入

为了更精确地控制注入，我们还可以使用条件注入：

inject({  // 只在需要的地方注入 process  process: {    id: path.join(__dirname, 'process-shim.js'),    // 可以添加条件，只在特定模块中注入    include: ['**/node_modules/**', '**/src/utils/**']  },  // 同时处理 global 对象  global: 'globalThis',  // 处理 Buffer 对象  Buffer: ['buffer', 'Buffer'],})

难点三：第三方依赖的

ESM/CJS兼容性问题

问题描述

某些第三方库（如 JSZip、@poizon/upload）在不同模块系统下的导入方式不同，导致打包后出现导入错误：

TypeError: Cannot read property 'default' of undefined

解决方案：混合导入处理

// 处理 JSZip 的兼容性导入let JSZipModule: anytry {  // 尝试 ESM 导入  JSZipModule = await import('jszip')  // 检查是否有 default 导出  JSZipModule = JSZipModule.default || JSZipModule} catch {  // 降级到全局变量  JSZipModule = (window as any).JSZip || require('jszip')}
// 处理 @poizon/upload 的导入import PoizonUploadClass from '@poizon/upload'
// 兼容不同的导出格式const PoizonUpload = PoizonUploadClass.default || PoizonUploadClass

在 Rollup 配置中加强兼容性处理：

export default {  plugins: [    resolve({      browser: true,      preferBuiltins: false,      // 解决模块导入问题      exportConditions: ['browser', 'import', 'module', 'default']    }),    commonjs({      // 处理混合模块      dynamicRequireTargets: [        'node_modules/jszip/**/*.js',        'node_modules/@poizon/upload/**/*.js'      ],      // 转换默认导出      defaultIsModuleExports: 'auto'    }),  ]}