多平台电商采购协同桌面端

本项目是一款面向电商运营与采购场景的 Windows 桌面客户端，采用 Electron 将 Web 技术与本地能力结合，前端使用 Vue 3 + Element Plus + Pinia 构建业务界面，数据通过 IndexedDB 做本地持久化，在保证离线可用与大量订单数据读写性能的前提下，实现与 聚水潭（ERP）侧订单数据 的联动管理。业务上覆盖从「待采购」到采购完成、发货、售后等多环节，核心目标是在 淘宝、1688、京东 等不同采购渠道之间，减少人工复制订单号、反复切换浏览器与后台的重复劳动，并将采购结果可靠地回写到本地订单列表，避免状态长期停留在「待采购」或信息缺失。

在技术实现上，主进程负责窗口生命周期、多店铺会话隔离（按店铺划分持久化分区）、IPC 消息转发及部分系统能力调用；预加载脚本在第三方电商页面中注入逻辑，完成自动填单、跳转、付款成功页识别等流程，并通过 IPC 将「采购成功」等事件安全送达主界面进程。渲染进程侧统一处理订单列表展示、筛选、导出以及与聚水潭相关的备注、解密等能力，并对订单主键采用 oid / soId / rawSoId 等多字段兼容匹配，降低因各平台 ID 形态不一致导致的关联失败。针对「采购完成后主界面未及时写入」类问题，设计上采用主进程侧短时确认与多 ID 登记策略，配合本地保存流程，提升写入成功率与可恢复性。此外，项目中还预留或集成了 Playwright 等自动化能力的使用场景，用于部分需脱离纯页面脚本完成的采集或操作任务。

整体上，该项目体现了 桌面端混合架构（主进程 / 预加载 / 渲染） 下的业务拆分、跨域与多窗口协作、以及电商 ERP 与多平台采购链路之间的工程化衔接，适合在简历中作为「复杂业务桌面工具 / 电商中后台工具链」类项目的代表案例呈现。

1. 多进程架构下的状态一致性与时序问题
Electron 主进程、渲染进程与带预加载的第三方采购窗口并行运行，采购结果依赖 IPC 异步传递。若主界面尚未完成订单列表更新与本地持久化，采购页已判定「成功」并关闭，会出现订单仍显示「待采购」或采购字段未回写。需在设计上区分「消息已送达」与「业务数据已落库」，通过短时轮询、多主键登记与写入完成后再确认等策略，平衡用户体验与数据一致性。

2. 跨平台订单标识不统一带来的关联难题
聚水潭与淘宝、1688、京东等渠道的订单号字段形态各异（如 oid、soId、rawSoId、内部 id），且存在字符串与数字混用。若仅以单一字段匹配，易出现「列表中有单、采购回写对不上」的隐性故障。需在业务层统一归一化比较规则，并在上报与校验链路中兼容多字段，降低误匹配与漏匹配概率。

3. 第三方页面环境下的稳定性与可维护性
电商站点 DOM 结构、路由与付款成功页 URL 会迭代更新，预加载脚本中的选择器、页面分支与延时逻辑面临脆弱性。需在有限的可观测性下做防御性判断、日志与降级（如刷新重试、避免在未找到订单时抛错阻断整条链路），并控制脚本复杂度，避免与业务渲染层强耦合。

4. 多店铺会话与安全隔离
不同采购账号对应不同 Cookie 与登录态，需按店铺划分浏览器会话分区，避免串号、串单。同时要在「自动化便利」与「用户数据隔离」之间取得平衡，这对窗口创建参数与 Session 管理提出明确要求。

5. 本地大数据量订单的持久化与性能
订单列表规模较大时，频繁写入若设计不当易引起界面卡顿或写入失败。采用 IndexedDB 等方案承载根数据、配合合理的保存策略与界面更新粒度，是保障长时间运行稳定性的必要考量。

6. 跨域、嵌入页与自动化能力的边界
在部分场景下，纯页面脚本难以覆盖全部流程，需引入或预留自动化能力（如 Playwright）作为补充，同时要理清与 Electron 窗口、网络代理及安全策略之间的协作方式，避免重复造轮子或引入难以排查的环境问题。