uni-app App端导出大数据需分段处理：chunkSize宜设20~50，避免OOM与IO过载；plus.io操作前须预检文件系统就绪，禁用并发写入，每段写入后让出主线程，并完善onerror与超时兜底。
直接在 uni-app App 端一次性导出上万条 JSON 或 Excel 数据，大概率会卡死、闪退或写入失败——这不是代码写得不对，而是内存和 I/O 调度在移动端根本扛不住。关键不是“能不能导”，而是“怎么分段、分时机、分权限去导”。
plus.io 写文件前必须确认文件系统就绪
很多闪退发生在 plus.io.requestFileSystem 回调没进来就直接操作目录，尤其是首次调用或 Android 12+ 权限未授予时。它不抛 JS 错误，但后续 dirEntry.getFile 会静默失败。
- 务必在
onLaunch或导出前主动调用一次plus.io.requestFileSystem并缓存fs实例，避免每次导出都重新申请 - 检查
plus.runtime.isReady和plus.storage是否可用，iOS 上部分机型plus.io在冷启动初期不可用 - 不要依赖
fs.root.getDirectory(..., {create: true})的同步创建效果；它实际是异步的，回调里才能确保目录存在
JSON 分段导出要控制 chunkSize 和并发写入
设成 chunkSize = 100 看似合理，但每段 JSON.stringify 后可能超 2MB，Android WebView 写入大字符串容易 OOM；而设成 10 又导致 IO 次数爆炸，耗时翻倍。
- 实测安全区间是
chunkSize = 20 ~ 50（视单条数据体积而定），建议先用JSON.stringify(item).length估算平均单条字节数，目标单文件 ≤ 512KB - 禁止并行写多个文件：
fileEntry.createWriter是串行 API，强行并发会导致write覆盖或onwrite乱序 - 每次
writer.write()后加setTimeout(() => {}, 0)让出 JS 主线程，避免 UI 完全冻结（尤其在低端 Android 设备）
导出 Excel 不能只靠 HTML 表格转 .xlsx
用拼接 <table> + <code>application/vnd.openxmlformats-officedocument.spreadsheetml.sheet MIME 类型骗过系统保存为 .xlsx，在 iOS 上基本失效；Android 部分厂商也拒绝识别这种“伪 xlsx”。
- 真正可靠的方式只有两种：
uni.downloadFile下载服务端生成的 .xlsx（推荐），或使用轻量库如xlsx（注意：仅支持小数据，1w 行以上极易内存溢出） - 若坚持前端生成，必须用
SheetJS (xlsx)的write方法 +arrayBuffer输出，再通过plus.io写入二进制文件，不能走 base64 字符串中转 -
.csv是最稳的选择：纯文本、无格式、无兼容问题，用plus.io直接写字符串即可，适合报表类导出
最容易被忽略的是错误兜底——用户点了导出，进度条走到 90% 卡住，你既没监听 writer.onerror，也没在 onwriteend 外加超时判断，结果用户以为成功了，其实最后几段根本没写进去。分段导出的本质是把一个原子操作拆成多个脆弱环节，每个环节都得有重试标记和断点续传意识。
