WordPress+WooCommerce 3万级商品电商系统架构方案咨询

前期数据预处理 #

• 先给全量分类、属性做全局唯一标识：把1个主分类+4级子分类的层级关系单独抽出来整理成映射表，给每一级分类、每个差异化属性都分配固定不变的全局唯一ID，不要直接用分类名、属性名做关联键，后续不管是分类改名、调整层级，还是对接ERP，都靠这个唯一ID做关联，省得以后改点东西就要全量刷数据。
• 拆分CSV字段属性：把所有字段分成两类，一类是商品核心通用字段（SKU编码、销售价、成本价、库存、主图链接、商品名、状态），一类是对应分类的专属差异化属性，两类字段分开存，不要混在一张大宽表里。
• 清洗完的数据留双份归档：一份是校验无误的原始结构化CSV备份，一份是拆成商品主表、分类映射表、属性定义表、商品属性关联表的分表结构化数据，不要只留导入站点后的数据库数据，避免以后站点出问题找不到原始标准数据。

存储架构设计（避坑重点，别为了性能丢兼容性） #

你想做自定义多表schema提升导入、查询效率的思路没问题，但别彻底绕开WooCommerce原生表结构，不然后续用生态插件、升级系统版本的时候全是临时兼容的烂活，合理的分层存储逻辑是：

• 商品核心交易字段、分类归属关联关系，必须存在WooCommerce原生的wp_posts、wp_postmeta、wp_term_relationships等官方标准表里，这部分不要瞎改，保证WooCommerce原生功能、官方生态插件能正常识别商品数据，不会出现升级后商品丢了、促销插件读不到价格这种低级问题。
• 分类专属的差异化属性、ERP对接需要的扩展字段，单独建自定义多表存储，表结构必须留三个固定字段：woo_product_id（关联WooCommerce原生商品ID）、global_product_uuid（跨系统全局商品唯一ID，ERP、后续新增的其他业务系统全用这个ID做关联，不要用数据库自增ID）、sync_updated_at（最后一次数据同步时间戳）。

踩过实坑提醒：3万商品的量级根本没到WooCommerce原生表扛不住的程度，大家吐槽原生导入慢，是因为默认导入工具每次导单条都会触发媒体处理、钩子回调、通知发送、索引重建一堆冗余逻辑，不是原生表结构本身性能差。别信什么全量替换原生表的方案，后期兼容成本能高到你想重构整个站。

全量导入流程 #

• 别用WooCommerce后台自带的CSV导入工具跑全量，那个工具导3万条大概率超时中断，还容易漏数据。
• 写离线CLI脚本跑导入，流程按顺序走：先批量导入分类、属性的term数据到原生分类/属性表，再批量导入商品核心数据到原生post表，接着批量关联分类、通用销售属性的对应关系，最后把分类专属的差异化属性写入自定义扩展表。导入过程临时关掉非必要的WooCommerce钩子、搜索引擎实时索引，导完再批量重建索引、跑全量数据校验。
• 导入完成后必须做三层校验：一是随机抽测单商品前台展示，确认分类、属性、价格库存显示正常；二是核对各分类下的商品总数和原始CSV统计值一致；三是抽10%以上的商品核对专属属性值，确认没有错配、漏导。

后续迭代、ERP对接兼容设计 #

• 所有跨系统数据同步统一用之前留的global_product_uuid做关联键，绝对不要用WooCommerce的自增商品ID、分类ID当跨系统关联依据，以后就算换站点、升级ERP、甚至换商城系统，只要这个全局ID不变，就不用做大量的数据映射兼容工作。
• 自定义扩展表的读写逻辑单独封装成独立工具类，不要直接改写WooCommerce原生的商品查询逻辑，要取扩展属性的时候单独调用工具类查询，后续就算WooCommerce大版本升级改了原生表结构，只需要调整工具类里的关联ID取值逻辑就行，不用全业务代码改一遍。
• 双向同步走消息队列，不要做系统间直连写库：WooCommerce端的商品、库存、订单变动推到队列同步给ERP，ERP端的商品、库存变动也推到队列同步给WooCommerce，队列里留全量操作日志，出问题能快速回溯，避免一边系统升级把另一边的生产数据写坏。

内容的提问来源于stack exchange，提问作者Thanos