根本原因是Windows版Excel对UTF-8四字节Unicode字符（如?、?、??）支持不完整，导致无BOM的CSV被误判为ANSI而显示方块；正确做法是手动构造带BOM的CSV并双引号包裹含Emoji字段，或改用xlsx.full.min.js生成原生支持Unicode的.xlsx文件。
导出含 Emoji 的单元格时 Excel 显示为方块或乱码
根本原因不是 layui 本身限制，而是 excel（尤其是 windows 版）对 utf-8 编码中四字节 unicode 字符（如 ?、?、??）支持不完整。layui table.exportfile() 默认生成 csv，而 windows excel 打开无 bom 的 utf-8 csv 时会误判为 ansi，导致 emoji 被截断或显示为 或空白方块。
必须加 UTF-8 BOM 且禁用默认 CSV 导出路径
别依赖 table.exportFile('id') 的快捷调用——它不加 BOM，也不处理 Emoji 字符边界。正确做法是手动构造带 BOM 的 CSV 字符串，并确保每个含 Emoji 的字段都被双引号包裹：
- 所有单元格内容先做
JSON.stringify()或自定义 escape：检测是否含 Emoji（可用正则/[\u{1F600}-\u{1F6FF}\u{1F900}-\u{1F9FF}\u{1F300}-\u{1F5FF}\u{1F1E0}-\u{1F1FF}]/u），满足即包裹双引号 - 内部已有双引号的需转义为两个双引号（
"→""） - 整段 CSV 字符串开头必须加
\ufeff（UTF-8 BOM） - 最终用
layui.table.exportFile(null, csvString, 'csv')传入字符串，而非数组
Emoji 在 Excel 中被自动转成图片或丢失格式
这是 Excel 渲染层行为，非数据问题。即使正确导出，Windows Excel 2016/2019 对某些 Emoji（如组合型 ??、?️?）仍可能降级显示或错位。应对策略：
- 若业务允许，导出前用
text.replace(/[\u{1F900}-\u{1F9FF}]/gu, '')过滤掉高版本 Emoji（保留基础表情） - 真要保全，必须弃用 CSV，改用
xlsx.full.min.js生成 .xlsx：它原生支持 UTF-8 字符，且能通过cell.v直接写入 Unicode 字符串，不经过 CSV 解析链 - 注意：
XLSX.utils.json_to_sheet()对含 Emoji 的字符串完全兼容，无需额外 escape
用 xlsx 全量导出时 Emoji 显示正常但文件体积暴增
这是因为 SheetJS 将每个 Emoji 当作独立字符存入字符串，而 .xlsx 格式本身不压缩文本。当单表含上千个 Emoji 单元格时，文件可能比纯文本大 3–5 倍。可优化点：
- 只对
title和用户输入列（如备注、昵称）启用 Emoji 支持，系统字段（ID、时间）跳过处理 - 导出前做轻量替换：将高频 Emoji 映射为短代码（
? → [good]），并在 Excel 侧用条件格式或注释说明 - 避免在
templet渲染中动态插入 Emoji 后再导出——容易漏 escape，应统一在数据层清洗
filename 或加 meta 标签绕过。 
