WordPress大数据量导入实施要点：分批、幂等与回滚

数据导入不是复制粘贴，而是对数据结构、服务器资源和业务逻辑的综合考验。数万条商品、数十万条订单、多年积累的会员数据，能否完整、可追溯地迁入新站，取决于方案设计而非工具选择。

先分清四种场景。 "数据导入"背后至少有四种需求：内容迁移，即文章、页面、媒体文件从旧内容管理系统搬入WordPress；业务数据导入，即商品、库存、会员、订单进入电商模块；持续同步，即外部系统每天推送数据，需要定时增量更新；历史归档，即海量只读数据不进入主内容表但需可检索。四种场景的方案完全不同，用一次性迁移的方案去做持续同步，后续必然失控。

官方导入器与通用插件有明确的边界。 内置导入器适合数百篇的小规模站点，它在一个请求内同步执行全部工作，受脚本执行时限与内存上限约束，规模上万后即不可靠。通用导入插件能覆盖多数常规需求，但存在四个边界：嵌套数据（多规格、多级分类）无法在映射界面表达；中途失败后重跑容易产生重复数据或覆盖人工修改；远程媒体下载超时导致内容缺失主图；错误只报失败结果，不提供行级定位。边界之内用插件提效，边界之外应转入定制开发。

可靠的导入架构遵循三个原则。 一是分批与断点：把一次大请求拆成小批次任务，在命令行环境执行以绕开网页请求的超时限制，每批记录处理位置，中断后从断点续跑而非从头再来。二是幂等：每条外部数据携带唯一标识，写入前先查询是新增还是更新，重复执行一百次结果一致——这是导入脚本与玩具脚本的分水岭。数据量达到数十万级时，唯一标识字段需建立索引或单独建映射表，否则查询会拖垮数据库。三是隔离与回滚：批量写入期间暂停修订版本生成、延迟分类计数、关闭缓存与优化类插件的保存钩子，结束后一次性重算；每批数据打上批次标记，出现问题可按批次精准回滚。

五个误区需要规避。 一是先导入再想结构：同一份数据可存为主内容、自定义文章类型、自定义表或元数据，选错则查询性能与扩展性全废，正确顺序是先设计数据模型再写脚本；二是用本地小数据量验收：必须以接近真实规模的数据在预发布环境压测，关注内存峰值与慢查询；三是忽略旧链接承接：数据搬过来而旧链接失效，数月后搜索流量大幅下滑，导入方案必须同步产出301重定向映射；四是没有回滚方案：无快照、无批次标记，连删除本次导入的内容都做不到；五是压缩测试、日志、文档这些不可见环节的投入，风险在上线后才集中暴露。

动手前的自查清单。 数据源是否已清洗（编码、空值、重复项）；每条数据是否有稳定的唯一标识；脚本能否重复执行而不产生重复数据；是否用真实规模数据在预发布环境验证过；服务器内存与数据库连接数是否评估；是否有完整备份与按批次回滚机制；旧站URL是否已有重定向映射；上线后由谁监控日志与处理异常。其中多项答不上来时，应先补方案再动手。

两个趋势值得关注。 一是接口与回调驱动的实时同步正在取代夜间批量文件交换，对增量识别与失败重试的要求更高；二是数据合规趋严，涉及会员个人信息的导入需考虑脱敏、授权与审计记录。

数据导入的本质是对业务的理解：字段如何映射、哪些数据该丢弃、历史订单是否保留原始状态，这些决策背后都是业务逻辑。先设计数据模型，再定导入方案，最后执行与验证——顺序不能颠倒。数据是企业最贵的资产，不应在一次草率的导入中受损。