Magento 2产品批量导入导出怎么做才不会把目录搞乱？

保哥把这些年帮独立站客户搬Magento目录踩过的坑都摊开讲：导入导出的本质是拿CSV当数据中转站，真正难的不是点哪个按钮，而是Add/Update、Replace、Delete三种行为选错一个就可能把全站商品引用清空。这篇按"搬什么数据→导出做模板→选对行为→对齐字段→喂图片和可配置商品→大批量不超时→报错定位→多店迁移"的顺序走一遍，每一步配上真实翻车现场，让你第一次导一万条SKU也能心里有底。

做出海独立站的朋友，十有八九都遇到过这种活：供应商甩来一张几千行的Excel，要你把商品一次性灌进Magento；或者老板要把整个目录导出来交给代运营改价格，改完再导回去。手工一条条录入是不可能的，那是给自己找罪受。Magento的批量导入导出就是干这个的，但它也是保哥见过翻车最频繁的功能之一——不是因为它难，而是因为很多人没搞懂它底下那套行为逻辑，一时手快就把生产库的数据冲掉了。

这篇就专门讲产品的CSV导入导出。它跟命令行运维那套bin/magento命令是两条线：那篇讲的是部署和编译，这篇讲的是数据怎么进出。两边偶尔会碰头（比如大批量导入要配合命令行跑索引），但解决的问题完全不同。咱们从最基础的概念捋起。

Magento的导入导出到底在搬哪些数据？

先把地图画清楚。Magento后台的入口在System（系统）菜单下的Data Transfer（数据传输）分组，里面分Import（导入）和Export（导出）两个口子。别小看这个分组名，"数据传输"四个字点破了它的角色：它不是数据库管理工具，而是一座连接外部表格和内部数据库的桥。

这座桥能搬的不只是商品。Magento把可导入导出的对象叫"实体类型"（entity type），官方支持的主要有这几类：

• Products（商品）——最常用的一类，商品的标题、价格、库存、图片、分类归属全在里头。
• Advanced Pricing（高级定价）——分组价、阶梯价这种，单独一张表管理，跟主商品表解耦。
• Customers and Addresses（客户与地址）——客户主数据和收货地址，迁站换平台时常用。
• Customer Finances（客户财务）——store credit、积分余额这类。
• Stock Sources（库存来源）——多仓库MSI场景下各仓的货品分布。

这篇只聚焦Products，但你得知道其它几类的存在。为什么？因为价格和库存虽然能跟着商品主表一起导，可一旦你的业务用上了分组价、多仓库，光导Products那张表是不够的，得配合Advanced Pricing和Stock Sources单独再导。

很多人导完发现"价格怎么没生效"，根子就在这——他改的字段压根不在主商品表的管辖范围内，分组价这种本来就该走Advanced Pricing那张独立表。把实体类型的边界搞清楚，能省掉一半莫名其妙的"导了没反应"。

还有一点要拎清楚：CSV是这座桥唯一通用的载体。Magento早年有个叫Dataflow的旧版导入机制，支持CSV和XML，后来在2.x里被废弃了，现在统一走CSV。所以你网上搜到老教程讲Dataflow Profiles的，直接跳过，那是上个时代的东西。当下就认准System > Data Transfer这套，外加一个能定时跑的Scheduled Import/Export（计划导入导出），那是给对接ERP、供应商每日同步用的进阶玩法。

导出CSV该怎么当模板用，哪些列删不得？

保哥给新人带活，第一条铁律就是：导入之前，先导出。哪怕你手头已经有供应商给的Excel，也别直接拿来用，先从Magento导出一张当前商品的CSV，拿它当模板，把数据往里填。

为什么这么讲究？因为Magento的CSV列名（column header）是有严格约定的，字段顺序、命名、多值分隔符都有讲究，你自己凭感觉拼一张表，十有八九对不上号。从系统里导出来的那张，每一列的名字天然就是对的。

导出的操作很直白：Export页面选Entity Type为Products，Export File Format选CSV，下面会列出所有属性（attribute）让你勾选过滤，不勾就是全量导出。点Continue，浏览器就下载一张完整的商品表。打开它你会看到几十甚至上百列，这就是你的标准模板。

导出还能反过来用作"体检表"。比如你怀疑某批商品的SEO字段没填全，导出时只勾sku、name、url_key、meta_title、meta_description这几列，下载下来在Excel里一眼就能扫出哪些行是空的，比在后台一个个点开商品看效率高太多。导出的字段过滤勾选，本质上是个轻量的批量查询工具，很多人只把它当备份用，白白浪费了这层价值。

这张表里有几列是命根子，删了或者改错了导入必崩：

这里面 sku 是核心中的核心，后面讲的所有行为逻辑都围着它转，先记住它是主键这件事。attribute_set_code 这一列特别坑新手：它填的必须是Magento里已经建好的属性集代码，你不能在CSV里凭空写一个新名字指望它自动给你建属性集——属性集得提前在后台建好，导入只认现成的。

导出还有个隐藏用法：它是你做"批量改价""批量换分类"最稳的姿势。流程是导出→在Excel里改那几列→用Add/Update行为导回去。比在后台一条条点快上百倍，而且改之前那张原始导出文件天然就是你的备份，改崩了拿它再导一次就回滚了。

保哥帮一个做户外装备的客户做季末调价，三千多个SKU的价格，就是这么十分钟搞定的：导出全量、只保留sku和price两列在Excel里批量乘折扣、Add/Update导回去。比让运营小妹在后台点三天靠谱多了，出错了原文件还在手边。

Add/Update、Replace、Delete这三种行为怎么选才不翻车？

来到这篇最要命的一节。Magento导入页面有个叫Import Behavior（导入行为）的下拉框，三个选项，每一个的破坏力天差地别。选错的代价不是导入失败那么温柔，而是可能把你生产库的数据真真切切地删掉。

保哥见过有人手一抖选了Replace，把上线两年攒下的商品评价、收藏关系全清了，那场面没法看——商品SKU看着还在，可底下挂的几百条真实评价、用户心愿单的关联全断了，因为那批商品在数据库里已经是被删了重建的新身份。咱们一个一个拆，把每种行为的脾气讲透。

Add/Update（添加/更新）——日常99% 用这个

这是最温和、最常用的行为。逻辑是：CSV里的SKU如果库里已存在，就用CSV的值更新它（除了SKU本身不能改），库里没有的就新建。它是"增量"思路，不动你CSV里没提到的商品。

但它有个非常容易踩的脾气：对多值字段（比如product_websites、categories），Add/Update只能加不能减。官方文档说得很清楚——如果某个商品原本绑了A、B两个分类，你导入的CSV里这一列只写了A，导完之后这个商品还是挂在A、B两个分类下，B不会被你"漏写"而删掉。

Magento的逻辑是：你没提B，不代表你想删B。要真想解绑，得用别的办法。这个特性救过很多人也坑过很多人，看你站哪头——指望靠少写一列来批量解绑分类的，会发现纹丝不动。

Replace（替换）——慎用，它会先删后建

名字听着像"更新"，其实凶得很。官方原话：如果导入数据里的SKU匹配到一个已存在的商品，所有字段连同SKU一起被删除，然后用CSV数据建一条全新记录。

关键就在"删除"两个字——老商品被整条抹掉，它在系统里的一切关联（评价、心愿单、历史订单的商品引用、URL重写记录）统统断链。新建出来的虽然SKU一样，但在数据库层面已经是另一个商品了（实体ID都变了）。前面那个清空评价的惨案，就是栽在这。

保哥的忠告：除非你非常清楚自己在干嘛，而且做了完整备份，否则别碰Replace。99% 你以为需要Replace的场景，其实Add/Update就够了。

Delete（删除）——只看SKU，其余列全忽略

这个行为最纯粹：它只读CSV的sku列，库里有这个SKU就删掉，其它列写什么它都不看。所以你做删除导入，CSV可以只留一列sku。有个小陷阱：如果CSV里某个SKU在库里根本不存在，Delete会报错——它不允许你删一个不存在的东西。

三种行为放一起对比更清楚：

除了行为，导入页面还有两个开关决定容错：Validation Strategy（校验策略）和Allowed Errors Count（允许错误数）。Validation Strategy有两挡：Stop on Error（遇错即停）和Skip error entries（跳过出错行继续）。Allowed Errors Count默认是10，意思是累计错误达到这个数就取消整个导入。

万行大表保哥一般把策略设成Skip，把允许错误数调高一点，先让能进的进去，再回头单独处理出错的那几行，比一遇错就全停效率高得多。一两行脏数据卡住整张表，太不划算。

字段映射最容易栽在哪几列？

导入报错，十次有八次是字段映射对不上。CSV的列名必须跟Magento的属性代码严丝合缝，而且某些列的值有特定的格式语法。保哥把高频翻车的几列单独拎出来说。

categories（分类）。这一列用斜杠表示层级、用逗号分隔多个分类。比如一个包同时挂在两个分类下，写法是 Default Category/Gear/Bags,Default Category/Collections。这里有两个坑要当心。

第一个坑是路径必须从根分类（通常是Default Category）写全，不能只写最后一级。第二个坑更阴——如果路径里的某级分类库里不存在，Magento会贴心地帮你自动创建。这"贴心"有时候是灾难：你Excel里多打一个空格或者拼错一个字母，它就给你建一个莫名其妙的新分类出来，分类树瞬间长出杂草，还得回头手工清。

url_key（URL键）。这是商品详情页URL的那一段。它在站内必须唯一，两个商品撞了同一个url_key，导入直接报"URL key for specified store already exists"。批量导入时如果你不显式给url_key，Magento会拿商品名生成，而名字相近的商品就容易撞车。改url_key还牵扯301跳转，改之前先想好老链接怎么办。

product_websites（站点）。填站点代码（website code），多站用逗号隔开。这一列空着的商品不会在任何前台显示——很多人导完一脸懵"商品明明在后台能搜到，前台怎么找不到"，八成就是这列漏了，或者前面说的visibility设成了Not Visible Individually。

说到 visibility（可见性），这一列也值得单拎出来。它常见四个取值：Not Visible Individually（不单独显示）、Catalog（只在分类页）、Search（只在搜索结果）、Catalog, Search（分类和搜索都显示，最常用）。可配置商品底下的那些简单子商品，正确做法是设成Not Visible Individually——让顾客只看到父商品那一个入口，子商品藏在规格选择里。

要是子商品也设成全可见，前台就会冒出一堆颜色尺码各自独立的条目，列表页瞬间被同款刷屏，体验很差，还会稀释父商品的权重。导入可配置商品时这一列特别容易设反，记得父商品全可见、子商品藏起来。

空值的处理。这是个微妙之处。在Add/Update行为下，某一列留空，Magento理解为"这个字段我不改"，保留库里旧值；如果你是真想把某个字段清空，得填特殊标记 __EMPTY__VALUE__ 才行。这个区别新手几乎都不知道，结果改了半天发现想清空的字段纹丝不动，还以为是缓存问题。

图片和可配置商品的列为什么总是导不进去？

这俩是导入界的"压轴题"，单独开一节讲。

先说图片。商品图相关的列主要有四个：base_image（主图）、small_image（小图）、thumbnail（缩略图）、additional_images（附加图，多张用逗号隔开）。值填的是图片文件名或路径。

关键问题是：图片文件本身放哪？Magento默认去 var/import/images/ 这个目录下找，你得提前把图片文件传到服务器的这个目录（或它的子目录）里，CSV里写相对路径。如果你在导入页面指定了Images File Directory，它就去那个目录找。这一步漏了，CSV里图片名写得再对，导进去也是一片裂图。

除了本地目录，Magento也支持远程图片——CSV里直接写图片的完整http/https网址，导入时它会去抓。这招迁站特别好用：老站的图片URL还活着的时候，新站导入直接引用老站地址，Magento自己把图抓过来落地。但有个前提，迁移期间老站的图片千万别提前关，不然抓到一半源没了，后面全是裂图。这坑保哥踩过，血泪教训。

再说可配置商品（configurable product）。这是Magento数据结构里最绕的一块。一个可配置商品（比如一件T恤）底下挂着若干简单商品（各种颜色尺码组合），CSV里要表达这种父子关系，靠的是 configurable_variations 这一列。它的语法是把每个子商品的SKU和决定变体的属性值串起来，子商品之间用竖线分隔。

导入的顺序也有讲究：得先把所有简单商品（子商品）导进去，再导可配置商品（父商品），否则父商品找不到它要关联的子商品，关联就建不起来。顺序反了，导入不一定报错，但变体就是挂不上，前台一选规格就缺货。

保哥的建议是，可配置商品别一开始就想着纯靠一张大表搞定。先用导出功能从一个手工建好的样板可配置商品导出CSV，照着它的configurable_variations写法依葫芦画瓢，比对着文档干瞪眼快多了。这也呼应前面那条铁律——遇事不决，先导出当模板。

大批量导入越导越慢甚至超时，根子在哪？

小表几百行，后台点一点秒进。但一旦上到几万行，问题就来了：页面转圈半天最后报504网关超时，或者进了一半莫名其妙断掉。这不是Magento不行，是你没给它配好环境。

根子通常在这几处：

• PHP执行时间和内存。max_execution_time 太短会被PHP自己掐断，memory_limit 太小会内存溢出。大表导入前把这俩调高。
• 上传文件大小。CSV文件默认上限受PHP的 upload_max_filesize 和 post_max_size 限制，后台界面那个2MB的默认提示就是从这儿来的。表大了得先把这两个值放开。
• 索引模式。每导一批，Magento默认要实时重建索引，这是拖慢的大头。把索引器（indexer）切到Update on Schedule（计划更新）模式，让它先攒着，导完再统一跑一次reindex，速度天差地别。
• Web请求超时。浏览器走HTTP导入，Nginx/Apache和PHP-FPM都有超时墙，大表很容易撞。

最后这条有个干净的破解法：别走后台，走命令行。Magento提供了 bin/magento 的导入相关能力，从SSH跑就绕开了Web请求的超时墙，大表更稳。这就跟前面提到的命令行运维接上了。

分批的粒度也有讲究。保哥的经验是单批控制在五千到两万行之间比较稳：太小了批次多、反复刷索引的额外开销摊不平；太大了又容易撞内存和超时。导之前先拿一小批跑一遍掐表，看单批耗时和内存占用，再据此定整批的切分大小，比拍脑袋一把梭安全得多。

导完别忘了组合拳：先 bin/magento indexer:reindex 重建索引，再 bin/magento cache:flush 刷缓存，不然你导的数据前台死活不更新。这套缓存和索引的配合，本质上和Magento性能调优里索引与缓存的逻辑是同一套底层机制，值得一并理解。

导入报错了，该从哪一行开始查？

Magento的导入校验其实挺友好，它会在Validate（校验）阶段就把错误列出来，而且带行号。所以排错第一步永远是：看它报的是第几行、什么错。别上来就怀疑整张表，八成是某几行的问题。

这里要分清两个阶段：先点Check Data做校验（validation），它只检查不写库；校验过了再点Import才真正落库。养成先校验、看清报告再导入的习惯，能在数据进库之前就把脏行揪出来，比导一半翻车再回滚省心得多。

高频错误对号入座：

最后那条编码问题，是中文卖家的重灾区。Excel在Windows上"另存为CSV"默认存的常常不是UTF-8，带中文的商品名导进去就是一堆乱码，或者带逗号的字段把列冲乱。解决办法是另存时明确选"CSV UTF-8"，或者用专门的工具转一道。

保哥之前写过多店架构的文章，里头多语言店铺的导入对编码的要求更苛刻，那种场景一个store view的翻译乱了码，整个店铺前台都跟着难看，这块不能马虎。

还有个实战技巧：大表报错先别全表硬刚。截前50行存成一个小CSV先试导，小表跑通了说明你的列结构和映射没问题，剩下的就是个别行的数据脏不脏，逐段排查比对着万行大表抓瞎高效得多。

多店和迁移场景下导入要额外当心什么？

单店导入搞明白了，多店和迁站是进阶。这里有几个单店时遇不到的坑。

store_view_code（店铺视图代码）这一列。多语言多店铺时，同一个商品在不同store view下有不同的名称、描述。CSV里表达这个靠的是分行：第一行store_view_code留空，填的是全局默认值（admin作用域）；后面再补几行，同一个SKU配上不同的store_view_code，填该店铺的翻译。

导入时Magento按store view把值分发到对应作用域。漏了这一列，你所有翻译都会被当成全局值，把默认值冲掉，多语言店瞬间变回单语言。

价格库存别忘了独立表。迁站时分组价、阶梯价这些得走Advanced Pricing单独导一张表，多仓库存走Stock Sources。只导Products主表，这些高级定价和分仓库存是上不去的——这正是开头那句"导了价格没生效"的真相。

迁站时的url_key与301。从别的平台搬到Magento，商品URL结构必然变。导入时如果让Magento自动生成url_key，新链接跟老链接对不上，老链接攒的权重就断了。稳妥的做法是导入时显式带上规划好的url_key，再把老链接到新链接的301映射做全，别让搜索引擎攒了几年的权重一夜清零。

升级前后的字段差异。Magento大版本升级（比如2.3到2.4），个别属性的代码或行为可能微调。如果你手头的CSV模板是老版本导出的，搬到新版本可能有零星字段对不上。保哥的习惯是：换了版本，第一件事重新从新环境导出一张空模板，拿它做基准，别拿老模板想当然。

这跟版本升级的兼容性核对是一个思路——升级后别假设旧资产还能原样用，先验再用。

说到底，Magento的导入导出是把双刃剑：用顺了它是你管理目录的核武器，几万条商品弹指间搞定；用岔了它能在几秒钟内把生产数据搅成一锅粥。掌握它的关键不在于背命令，而在于理解它底下"行为决定生死、字段决定成败"这套逻辑。导入前先备份、先小样试导、看清楚选的是哪个行为——这三条做到了，你就比绝大多数人稳了。

常见问题解答

导入用Add/Update，为什么CSV里删掉的分类商品还挂着？

这是Add/Update行为对多值字段的设计特性，不是bug。对product_websites、categories这类能填多个值的字段，Add/Update只增不减——你CSV里没写的分类，Magento理解为"你没提到"，而不是"你要删除"，所以库里原有的绑定会保留。想真正解绑某个分类，要么改用其它处理方式单独操作，要么理解清楚后在后台手工调整。这也是为什么改多值字段前一定要想清楚预期。

Replace和Add/Update到底差在哪，什么时候才该用Replace？

差别是天壤之别。Add/Update是在原商品基础上更新字段，商品的实体ID不变，评价、心愿单、订单引用这些关联全部保留。Replace是把匹配到的老商品整条删掉（连SKU一起），再用CSV建一条全新记录，实体ID都变了，所有系统关联断链。绝大多数"更新商品"的需求用Add/Update就对了。Replace只在你明确要彻底重置某批商品、且接受关联数据丢失、且做好了完整备份的极端情况下才考虑，日常运营基本用不上。

导入大表总是超时或者中途失败，有什么稳妥办法？

先从环境下手：调高PHP的max_execution_time和memory_limit，放开upload_max_filesize和post_max_size让大文件能传上去。再把索引器切到Update on Schedule模式，避免每批都实时重建索引拖慢。最关键的一招是别走后台网页导入，改用bin/magento的命令行方式从SSH跑，直接绕开Web请求的超时墙。导完记得手动重建索引并刷新缓存，否则前台看不到新数据。万行级别的表，还可以拆成几个小文件分批导。

商品图片在CSV里写了文件名，导入后图却出不来，问题在哪？

多半是图片文件没放对地方。Magento默认去服务器的var/import/images/ 目录下找图片文件，你得提前用FTP或SCP把图片传到这个目录（或它的子目录），CSV里写相对路径。如果你在导入页面指定了Images File Directory，就去那个目录找。另一种方式是CSV里直接写图片的完整网址，让Magento去远程抓——这时要保证那个网址在导入期间一直可访问，迁站时老站图片别提前下线。

中文商品导入后变乱码或者字段错位，怎么解决？

根源是CSV文件编码不对。Excel在Windows下默认"另存为CSV"常常用的是本地编码（GBK之类）而非UTF-8，中文导进Magento就成乱码；字段错位则多半是某个字段内容里带了逗号，把列冲乱了。解决办法：另存时明确选"CSV UTF-8（逗号分隔）"格式；字段内含逗号的要确保被引号正确包裹。还有一招最稳——从Magento先导出一张样板CSV，它的编码和分隔符天然是对的，拿它当模板往里填数据，从源头上避免这类问题。

权威参考资料