一、大数据量下的传输方案localStorage 单域容量通常在 5MB 左右数据量级上限可控但直接全量一次性传输仍存在请求体超限、弱网超时、中断后全量重传等问题推荐按「轻量化优化 分批上传」的思路处理。传输前的 payload 瘦身优化先降低单次传输的数据体积从源头减少传输压力• 字段精简映射将长字段名替换为短别名如 shopId→id、name→n、addedAt→t后端接收后再映射回原字段可减少 20%~40% 的 JSON 冗余体积。• 数据压缩使用 pako 等前端压缩库对 JSON 字符串做 gzip 压缩以 ArrayBuffer 二进制或 base64 格式传输通常能压缩 60%~80% 的体积适合单批数据量较大的场景。• 字段裁剪与校验仅传输后端存储必需的字段剔除前端本地冗余字段上传前先做 JSON 合法性校验避免解析异常导致上传畸形数据。核心方案分批分片上传针对数组型数据最稳妥的方式是按条数切片、分批次上传兼顾可靠性与实现成本。• 切片规则将本地数组按固定条数拆分建议单批 100~500 条根据单条数据大小调整控制单请求体在 100KB 以内生成批次列表。• 请求约定每个批次请求携带统一的迁移任务ID、当前批次号、总批次数、当前批次数据便于后端按任务聚合、按批次校验。• 并发控制采用串行或 2~3 个低并发上传避免触发网关限流、占用过多浏览器连接数弱网环境下优先串行。• 优势单请求体积小、超时概率低失败仅需重传对应批次无需全量重传可实现可视化进度用户体验更好。后续同步优化增量同步首次全量迁移完成后日常同步无需再传全量数据• 本地维护 lastSyncTime 同步时间戳每次同步成功后更新。• 后续仅上传 addedAt / updateAt 大于该时间戳的新增/变更数据大幅减少传输量。二、网络异常、上传不全的可靠性保障核心思路是幂等兜底 断点续传 重试容错 最终对账确保数据最终一致不丢不重。接口幂等性设计基础底线从后端层面避免重复上传导致脏数据是所有重试、续传的前提• 数据级幂等以 shopId 作为唯一主键后端存储采用 upsert存在则更新、不存在则插入逻辑同一条数据重复上传不会产生重复条目。• 批次级幂等为每个批次生成唯一 batchId后端记录已处理完成的批次ID。重复请求同一批次时直接返回成功不重复写入。断点续传 本地进度持久化解决「传了一半断网/刷新页面要从头开始」的问题• 迁移启动时在 localStorage 中写入迁移进度记录包含任务ID、已完成批次号、已上传条数。• 每成功完成一个批次立即更新本地进度。• 异常中断后重新启动迁移时先读取本地进度直接从下一个未完成的批次继续上传跳过已成功的部分。• 全量上传且对账通过后再清除进度记录与旧的本地数据。分级重试策略针对不同失败原因做差异化处理兼顾成功率与性能• 瞬时故障重试对网络超时、5xx 服务端错误、DNS 抖动等瞬时异常采用指数退避重试间隔 1s → 2s → 4s单批次最多重试 3~5 次。• 错误分类处理4xx 参数错误、权限错误等业务异常不重试直接标记为失败并记录原因仅网络类、服务端瞬时故障触发重试。• 失败隔离单个批次重试耗尽仍失败时先标记为异常继续推进后续批次最后统一处理失败批次不阻塞整体迁移进度。最终一致性对账校验全批次上传完成后必须做一次完整性校验避免「传完了但缺数据」的情况• 前端计算本地全量数据的总条数、按 shopId 排序后的哈希值。• 后端返回对应任务在 DB 中的总条数、对应哈希值两端做对比。• 若对账不一致后端返回缺失/异常的 shopId 列表前端针对性补传对应条目若差异过大降级为重新全量分批上传。兜底回滚机制确保迁移失败不影响原有业务• 延迟删除本地数据迁移过程中、对账通过前绝对不删除 localStorage 中的原始数据。只有确认后端数据完整一致后再清理本地数据。• 业务降级迁移未完成/失败时前端业务继续读取本地 localStorage 数据不强制切换到后端用户无感知。• 后端可回溯迁移数据携带 migrate_task_id 标识若出现脏数据可按任务维度快速清理不污染正式业务表。补充工程建议• 阈值降级数据量小于 50 条时直接走单请求全量上传无需分批降低实现复杂度。• 进度可视化给用户展示迁移进度条、当前状态上传中/成功/失败失败后提供手动重试按钮。• 埋点监控上报迁移成功率、失败原因、平均耗时、数据量级便于后续迭代优化。需要我帮你整理一份可直接落地的前端迁移核心代码示例吗
