uni-app用uniCloud导出Excel的核心是解决“在哪导、怎么导、导完怎么给用户”三步错位：云函数须用node-xlsx生成Buffer，通过callFunction调用并返回base64结构，小程序端 writeFile后openDocument，注意分页查询、路径编码及平台兼容性。
uni-app 用 uniCloud 做数据统计导出，核心不是“能不能”，而是“在哪导、怎么导、导完怎么给用户”——绝大多数失败都卡在这三步的错位上。
云函数里生成 Excel 文件必须用 node-xlsx + Buffer，别碰 xlsx（前端库）
uniCloud 云函数运行在 Node.js 环境，不支持浏览器 DOM 和 File 对象。很多开发者直接把前端导出逻辑搬过去，调用 xlsx.write() 返回一个 ArrayBuffer 就完事，结果云函数返回空或报错。
-
node-xlsx是专为服务端设计的轻量库，能直接生成.xlsx的二进制Buffer，兼容性好、无依赖冲突 - 千万别用
xlsx（SheetJS），它在云函数里 require 会失败，或生成的 Buffer 缺少 ZIP 头导致文件损坏 - 生成后必须用
Buffer而非字符串：写入云存储或直接返回时，Buffer.from(data, 'binary')比new Buffer(data)更安全（后者在 Node.js 14+ 已废弃）
uni.downloadFile 在小程序里无法直连云函数 HTTP 地址，得走 uniCloud.callFunction
小程序端调用云函数获取 Excel 数据时，如果用 uni.request 请求云函数的 HTTPS 地址（比如 https://xxx.service.t.cloudbase.net/export），99% 会失败——这不是域名白名单问题，而是云函数默认不暴露公网 HTTP 接口（除非你手动部署为 HTTP 函数）。
- 正确路径是：
uniCloud.callFunction({ name: 'exportExcel', data: { query: {...} } }) - 云函数返回值必须是
{ code: 0, data: { buffer: 'base64 string', filename: 'report.xlsx' } }这类结构，不能直接返回Buffer（JSON 序列化会丢数据） - 小程序端收到 base64 后，要用
uni.getFileSystemManager().writeFile写入本地，再用uni.openDocument打开；uni.downloadFile只适用于后端已提供可访问 URL 的场景
导出大量统计数据时，uniCloud.database 查询必须加 .limit() 或分页，否则云函数超时
uniCloud 免费版云函数单次执行限时 5 秒，付费版最多 60 秒。如果你的统计集合有 10 万条记录，collection.where(...).get() 一次性拉全量，大概率超时或内存溢出。
- 先用
.count()判断总量，超过 5000 条就提示“建议按日期范围导出” - 真要全量导出，必须配合
.skip()+.limit(2000)分批次查，每次生成部分 Sheet，最后合并（node-xlsx支持多 sheet） - 避免在云函数里做复杂聚合：统计逻辑尽量前置到云数据库的聚合管道（
.aggregate()），别在 JS 里forEach算指标
导出文件名含中文时，uni.openDocument 在 iOS 上会失败，必须 URL 编码
小程序调用 uni.openDocument 打开本地 Excel 时，如果 filePath 包含中文（比如 /wxfile/销售统计-20260618.xlsx），iOS 端会静默失败，Android 正常——这是微信底层文件系统对路径编码的差异。
- 写入文件前，对文件名做
encodeURIComponent：const safeName = encodeURIComponent('销售统计-' + Date.now() + '.xlsx') - 但注意：
uni.openDocument的filePath是完整路径，不是文件名，所以最终路径应为${wx.env.USER_DATA_PATH}/${safeName} - 更稳妥的做法是全程用英文名 + 时间戳，导出后在 UI 层显示友好名称（如“销售统计（2026-06-18）”），避免路径层参与语义
真正麻烦的从来不是“怎么生成 Excel”，而是“怎么让云函数吐出能被小程序稳稳接住的二进制流，且不因数据量、平台差异、路径编码崩在最后一环”。每一步的隐式约束都得亲手验证，光抄代码没用。
