浏览器直接打开CSV而非保存，因download属性仅对同源URL或blob:有效；需后端返回Content-Disposition: attachment及UTF-8 BOM，前端用fetch+Blob避免乱码与卡顿。
点击下载 CSV 日志时浏览器直接打开而不是保存怎么办
HTML 本身不能强制触发「另存为」行为，download 属性只在同源 URL 或 blob: 协议下生效；如果链接指向一个真实服务器路径（如 /api/logs?format=csv），多数浏览器会根据响应头 Content-Type: text/csv 和 Content-Disposition 决定是预览还是下载。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 后端必须返回
Content-Disposition: attachment; filename="audit_log_202410.csv"，否则前端加download属性也无效 - 避免用
<a href="/logs/export">导出</a>直接跳转，改用 JS 触发：先 fetch 获取 CSV 内容，再构造Blob+URL.createObjectURL，最后模拟点击带download的链接 - 若必须用纯 HTML 链接，请确认 Nginx/Apache 已配置该路径的默认响应头，例如 Nginx 中添加：
add_header Content-Disposition "attachment";
前端生成 CSV 内容时中文乱码（Excel 打开是方块）
根本原因是 Excel（尤其 Windows 版）默认用 ANSI/GBK 解析 CSV，而前端生成的文本通常是 UTF-8 编码。不加 BOM，Excel 就认不出。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 构造
Blob时必须加 UTF-8 BOM：new Blob(['\ufeff' + csvString], {type: 'text/csv;charset=utf-8'}) - 不要用
encodeURI或encodeURIComponent处理整段 CSV——它们会把逗号、换行符也编码，破坏格式 - 字段含换行符或双引号时，需按 RFC 4180 转义：用双引号包裹字段，字段内双引号写成两个（
"→""），再整体包一层双引号
审计日志导出需要权限校验，但 HTML 链接无法携带 token 怎么办
HTML <a> 标签发起的 GET 请求无法自动注入 Authorization header，把 token 放 query 参数（如 ?token=xxx）既不安全又易泄露（进 access log、浏览器历史、代理缓存）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 放弃纯 HTML 链接，改用
fetch发起带Authorization: Bearer <token>的请求，后端校验通过后返回 CSV 数据 - 后端接口应限制为 POST（防 CSRF 可配合
SameSite=StrictCookie），或要求 Referer 匹配白名单域名 - 若必须用 GET，token 应由后端短期签发（如 60 秒有效期）、绑定用户 IP 和 UA，并在签发后立即失效旧 token
大日志导出卡死页面或内存溢出
前端拼接几万行 CSV 字符串再生成 Blob，容易触发 JS 堆内存报警（尤其低配设备），且用户无法感知进度。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 禁止前端组装全量数据；应由后端流式输出（
Transfer-Encoding: chunked），前端用response.body.getReader()分块读取并写入WritableStream（需检查浏览器支持） - 更稳妥的做法：前端提交导出请求后，返回一个任务 ID；轮询
/api/export/status?id=xxx，完成后提供带时效签名的临时下载地址（如/export/dl/abc123?expires=1699999999&sig=xxx） - CSV 行数超 5000 时，前端应禁用直接导出按钮，提示「请使用后台任务导出」
真正难的不是拼 CSV 字符串，而是让导出过程可中断、可追溯、不暴露敏感凭证，同时兼容 Excel 对编码和格式的“怪癖”。BOM、Content-Disposition、流式响应这三点漏掉任一，用户点十次都可能打不开。
