html导出是伪导出，仅将html字符串交由excel渲染；excel下载是真导出，生成标准.xlsx二进制文件。前者易致损坏、乱码、样式错乱及ios/safari失效，后者通过sheetjs writefile()保障格式正确、兼容性强、支持多sheet与中文。
不冲突，但“HTML导出”和“Excel下载”根本不是同一类操作——前者是把 HTML 字符串当 Excel 打开（伪导出），后者是生成真实 .xlsx 文件并下载（真导出）。混用会导致文件损坏、样式错乱、Safari/iOS 失效、中文乱码等一堆问题。
为什么 data:application/vnd.ms-excel 会损坏 .xlsx 文件
这个 MIME 类型本意是让 Excel 渲染 HTML 内容，不是生成 .xlsx。浏览器把它当“HTML 文本”处理，a.href = 'data:application/vnd.ms-excel;base64,...' 后强制加 .xlsx 后缀，Excel 就会报“文件已损坏”或直接拒绝打开。
诊断并修复涉及公式、命名范围、Power Query 刷新、数据透视表、VBA/宏保存等问题的 Microsoft Excel XLSX 工作簿
- 它只兼容老式 .xls 渲染逻辑，对 .xlsx 的 OOXML 结构完全无视
- base64 编码的 HTML 表格里若有
<col width="80">或内联style="text-align:center"，Excel 解析时大概率跳过或错位 - Chrome 90+ 已逐步限制 data URI 自动下载行为，
a.click()可能静默失败 - Safari 和所有 iOS 浏览器根本不支持
download属性作用于 data URI，必须降级为window.open()，但又无法控制保存名和格式
XLSX.utils.table_to_sheet() 和 table.outerHTML 的本质区别
前者读取 DOM 节点结构（<thead>/<code><tbody>/<code><tr>/<code><td>），转成二维数组再封装为 SheetJS 的 <code>Worksheet 对象；后者只是把 HTML 字符串原样塞进 data URI，Excel 得自己猜结构。
-
table_to_sheet()能正确处理rowspan/colspan，自动合并单元格；outerHTML方式会把合并单元格渲染成重复内容或空列 -
table_to_sheet()默认忽略 CSS，但可通过cellStyles: true选项启用基础样式（如粗体、背景色），而 data URI 完全不认 CSS - 如果表格里混了
<div> 或 <code><span></span>，table_to_sheet()会跳过它们；outerHTML则照单输出，Excel 解析时直接崩溃为什么
XLSX.writeFile()比a.download更可靠XLSX.writeFile()底层调用的是Blob+URL.createObjectURL()，绕过了 data URI 的长度限制和 MIME 校验，生成的是标准 OOXML 二进制流。- 支持完整 .xlsx 特性：多 sheet、公式、冻结窗格、条件格式（需配合
XLSX.utils.aoa_to_sheet()或手动写入） - 中文不会乱码：
XLSX.writeFile()默认写入 UTF-8 BOM，Excel 2016+ 能正确识别 - 文件大小无硬限制：data URI 在 Chrome 中超过 2MB 就可能截断，
Blob没这问题 - 兼容性明确：IE11+、Chrome 90+、Edge、Firefox 全支持；Safari 15.4+ 也支持
writeFile()（旧版 Safari 需 fallback 到writeFileAsync()）
真正要协同，就别让 HTML 导出和 Excel 下载共存于同一套逻辑里。前端该用
XLSX.utils.table_to_sheet()+XLSX.writeFile()，后端该用openpyxl或exceljs——中间那条“用table.outerHTML拼 data URI”的路，看着省事，实则埋雷最多，尤其在需要 colspan、中文、多 sheet 的场景下，第一份导出文件就可能打不开。 - 支持完整 .xlsx 特性：多 sheet、公式、冻结窗格、条件格式（需配合
