导出日志按钮需用 Blob + createObjectURL + a.download 实现下载，时间比较须统一转毫秒，UTF-8 TXT 要加 BOM（\ufeff），大日志需截断至10000条防卡顿。
HTML里怎么加个“导出日志”按钮，又不卡页面
浏览器原生不支持直接导出控制台日志，所谓“导出”，本质是把前端收集的日志数据（比如 console.log 拦截后的数组）转成文件下载。关键不是渲染，而是触发下载行为。
常见错误：用 window.open('data:text/plain,...') 或伪造 a 标签 href 但没设 download 属性 → 在 Safari 和部分新版 Chrome 里会被拦截或打开新页而非下载。
- 用
URL.createObjectURL(new Blob([content], {type: 'text/plain'}))创建临时 URL - 动态创建
a元素，href设为该 URL，download设为带日期的文件名，如log-20240520.txt - 调用
a.click()后立即URL.revokeObjectURL()防内存泄漏 - 别在
console.log里直接 push 原始对象 —— 要JSON.stringify过，否则导出的是[object Object]
按日期范围筛选日志时，时间字段怎么处理才不出错
前端日志的时间戳通常来自 Date.now() 或 new Date().toISOString()，但用户选的日期范围（比如 <input type="date">）返回的是本地时区的 YYYY-MM-DD 字符串，直接比大小会跨时区错乱。
典型现象：选了 “2024-05-20”，结果漏掉当天 00:00–08:00 的日志（因 UTC 时间还属 19 日）。
立即学习“前端免费学习笔记（深入）”；
- 统一转成毫秒数比较：把日期输入转成当日 00:00 和 23:59:59.999 的
Date对象，再用.getTime() - 如果日志时间存的是 ISO 字符串（如
"2024-05-20T14:22:03.123Z"），用new Date(logTime).getTime()安全，它自动按 UTC 解析 - 避免用字符串截取（如
logTime.slice(0,10) === '2024-05-20'）—— 时区不同会导致结果不稳定
导出内容包含中文或特殊符号，打开乱码怎么办
Windows 记事本默认用 GBK 打开 TXT 文件，而前端生成的 Blob 默认是 UTF-8 编码，没 BOM 就会识别失败，显示乱码。
不是前端显示问题，是下游软件（尤其是 Windows 自带记事本）的编码猜测机制缺陷。
- 最稳方案：导出为
.csv或.json，它们天然支持 UTF-8，Excel 和 VS Code 都能正确读取 - 非要 .txt：在
Blob内容前加 UTF-8 BOM（\ufeff），即new Blob(['\ufeff' + content], ...) - 别用
encodeURI或encodeURIComponent处理整个日志内容 —— 它们是为 URL 设计的，会把换行符、引号等搞乱
日志量大时点导出就卡死？内存和性能怎么控
一次导出几万条日志，JSON.stringify(allLogs) 可能占几百 MB 内存，触发浏览器警告甚至崩溃，尤其在低端 Android 设备上。
这不是功能做错了，是没做流式切割。
- 限制单次导出最多 10000 条，超量则提示“请缩小日期范围”，并给出当前筛选后总条数（
logs.length） - 导出前先用
logs.filter(...).slice(0, 10000)截断，别对原始全量数组操作 - 不用
reduce拼接大字符串，改用数组map+join('\n')，V8 对后者优化更好 - 如果真要支持海量导出，得走后端：前端只传筛选条件（
startTs,endTs,level），后端查库、分片、流式响应
日期范围筛选和导出按钮看着简单，但时间解析、编码兼容、内存水位这三块，随便漏一个，用户点一下就报错或打不开文件。实际项目里，八成问题都出在这三个地方，而不是逻辑本身。
