SAP WM组织模型详解：仓库号、存储类型与仓位层级设计

简介：面向SAP仓储管理初学者与WM模块实施顾问整理的中英文术语对照与概念解释文档，聚焦仓库组织结构和主数据，帮助读者解决阅读英文配置界面、参与实施沟通时术语不熟、概念混淆的问题，适合作为入门查阅与项目速查的参考材料。压缩包内为1个docx文件，约16KB，篇幅精炼，按Plant、Storage Location、Warehouse Number、Storage Type、Storage Section、Picking Area、Staging Area、Storage Bin等条目逐项给出中文译名与释义，并延伸说明仓库号与仓库联合体的组织关系、存储类型与存储分区的划分逻辑、拣货区在出库策略中的作用，以及仓位的最大载重量、总能力、防火分区、仓位类型等主数据字段，术语与业务场景相互印证，便于对照理解而非孤立记忆。该文档已有999人学习下载，适合作为WM学习笔记或实施现场的中英对照速查表反复使用。

1. 仓库号管一片建筑群：SAP WM 组织模型里最反直觉的一层

第一次接触 SAP WM 的人，看到那份中英文对照表，很容易把它当成一本词汇手册：Plant 是工厂、Storage Location 是存储地点、Warehouse Number 是仓库号、Storage Bin 是仓位，一行一行背下来就算入门了。这份对照表里真正值钱的信息是这些词之间的层级关系：从工厂一路收敛到某一层货架上的某一格，整条链上的每个单元各管一件事。最容易理解错的是 Warehouse Number。系统里的仓库号并不对应某一栋建筑，它更像一个仓库联合体的管理单元，把高架库、堆放区、拣货区乃至同厂区里的溢出库，全压在一个编号下面统一调度。按“一栋楼一个仓库号”去配，后面几乎一定要返工。

2. 工厂、存储地点、仓库号：三套组织层级为什么必须同时存在

2.1 IM 记的是「有多少」，WM 记的是「在哪里」

库存管理（IM）和仓库管理（WM）在系统里是两套账，这两套账的粒度完全不一样。IM 这一侧，Plant 工厂是后勤与成本核算的组织单元，Storage Location 存储地点是库存的记账单位——它只回答“这个物料在这个地点上有多少件”，不回答“放在第几排第几层”。WM 这一侧，Warehouse Number 仓库号才真正接管了物理位置，往下一层层拆到存储类型、存储分区、仓位。

顺带说一句，输入材料里有两个常见的拼写笔误：Warehoue Number 应为 Warehouse Number，Tranfer Order 应为 Transfer Order。正确写法是 Transfer Order 转储单、Transfer Requirement 转储申请，这两个词后面会反复出现。

把这几层摊开看，它们回答的问题是这样分工的：

关键在存储地点和仓库号之间的映射方向。一个存储地点会指向一个仓库号，但反过来，一个仓库号可以挂住多个存储地点，甚至跨工厂。也就是说，工厂到存储地点是一对多，存储地点到仓库号是多对一。这条多对一的关系，正是“一个仓库号管一片建筑群”能成立的结构基础——只要这些建筑在管理上属于同一个仓库联合体，它们的库存在 IM 侧可以分散在好几个存储地点记账，在 WM 侧却收敛到同一个仓库号统一调度。

实际业务里，这条链跑起来是这样：采购收货在 IM 侧按存储地点记账，同时生成一张转储申请（Transfer Requirement），再由它生成转储单（Transfer Order），WM 才真正去某个仓位上把货放下来。IM 只知道“进来了 100 件”，WM 才知道“这 100 件进了 01 存储类型下的 A 分区第三层”。两套账各记各的，靠 TR 和 TO 串起来。搞不清这条边界，后面所有的配置讨论都是空的。

2.2 仓库联合体的边界：地理距离和组织归属谁说了算

仓库号的划分标准，输入材料给得很明确：推荐用一个仓库号管理某一地域的一组仓库建筑群，也就是仓库联合体；如果几个仓库设施在地理区域上隔得很远，就该考虑拆成分别的仓库号。一般同一个工厂区用一个仓库号。

这条规则听起来简单，落地时的判断点在于“远”到底怎么定义。我的理解是，判断依据落在物理移动的成本上，直线距离本身不是重点——两个库之间要不要靠卡车倒运、倒运一次要不要半天、盘点时能不能同一批人跑完，这些才是真正的分界线。同一个厂区里，高架货架区、堆放区、固定仓位拣货区、收货区、发货区、外部存储区域（特别货物存储区或溢出区）统统可以塞进一个仓库号，因为它们之间的移动靠叉车几分钟就能完成，属于同一个管理节奏。

反过来，如果两个库区之间要跨城调拨，硬塞进一个仓库号会带来一堆别扭：转储单在两栋楼之间来回跑，但实际执行的运输周期完全不受 WM 控制；盘点周期没法统一；负责人的管理半径也对不上。这种时候拆成两个仓库号，各自独立运转，跨库的移动在 IM 层面处理，反而更干净。

有一种边界情况值得单独提：同一厂区内的独立建筑。材料里说一个仓库号可以管理多个独立的仓库建筑，称之为仓库联合体。注意这里的“独立”是物理独立，不是管理独立。只要仓储策略、人员归属、作业节奏是一套，物理上分散成几栋楼并不构成拆分的理由。反过来说，即便两栋楼挨着，如果一栋归甲部门管、一栋归乙部门管，作业标准都不一样，那就该考虑拆开了。

2.3 仓库号级别挂载了什么：计量单位和模块接口

仓库号之所以能当管理单元，是因为很多跨模块的东西是挂在它这一级的。材料里点了两个：仓库管理使用的单位，以及 WM 和其他模块（比如 PP）的接口。

计量单位这一条容易被忽略，但它决定了整个仓库的作业口径。同一个物料，采购按箱买、生产按件领、仓库按托盘存，如果仓库号级别不把基准单位定下来，仓位容量、载重、搜索顺序这一整套判断就全乱套。这个单位定在仓库号这一级而不是物料主数据这一级，背后的逻辑是：同一个物料在不同仓库的存储形态本来就可能不一样，把口径绑在仓库上比绑在物料上更贴近现实。

接口这一条更直接。WM 与 PP 的接口做在仓库号级别，意味着生产领料的触发逻辑、看板补货的粒度，都是按仓库号来组织的。这也是为什么仓库号的划分不能随便改——它一旦定下来，下游挂在上面的接口、单位、策略配置全都要跟着动。改一个仓库号，约等于重建一套仓库管理。

提示：划仓库号的时候，先把“以后会不会拆”想清楚。这个决定不像物料主数据那样可以随手改，它上面挂着接口、单位和一整套策略配置，动一次伤筋动骨。

3. 存储类型与存储分区：两级切分背后的控制参数继承

3.1 叫「类型」的存储对象，其实是一块仓储区域

Storage Type 这个英文词容易误导人，让人以为它是某种类别标签。材料里说得很清楚：它实际上称作存储区域更合适，指的就是一个存储区域，包括仓储设备和仓储区。它在仓库号下面定义，可以是物理区域，也可以是逻辑区域。

切分的依据有四种，材料里列全了：仓储技术（自动仓、半自动仓、高架货架等）、使用空间区域、组织形式、功能。这四种依据对应四种完全不同的切法，实际项目里往往是混着用的。按仓储技术切，出来的是高架货架区、堆放区、货架区；按功能切，出来的是收货区、发货区、差异区；按空间切，出来的是某个具体的库房。

常用的存储类型有这么几类：Bulk storage 堆货区、Open Storage 开放区、High rack storage 高架货架区、Picking area 拣货区、Shelf storage 货架区。另外还有一类特殊角色，是 WM 和 IM 共用的中间存储类型，包括 Goods receipt area 收货区、Goods issue area 发货区、Interim storage area for differences 差异区、Posting change zone 过账变更区。这类中间区域的意义在于，它们是两个系统之间的缓冲带——货从 IM 侧进来，先在收货区落一下，等 WM 决定去哪个最终仓位，再移动过去。缓冲区不是可有可无的装饰，它是把“记账完成”和“物理落位完成”这两个不同步的事件解耦开的装置。

还有两个词在这套体系里位置比较边缘但绕不开：Staging Area 集结区和 Door 门。集结区是出库前的临时堆放点，门是装车点，它们通常也被定义成存储类型，因为它们同样需要被 WM 管理——货在集结区等车的时候，系统得知道它在哪里。

3.2 预定义存储类型里预置了哪些控制参数

标准系统里已经预定义了几个常用的存储类型，包括一个高架区、一个堆放区、一个拣货区等等。这些预定义类型的价值不在于省事，而在于它们已经把一批控制参数配好了：上架策略、下架策略、盘点方法。

这三组参数是存储类型的核心。上架策略决定货进来往哪儿放，下架策略决定出货从哪儿取，盘点方法决定怎么盘。它们定义在存储类型这一级，意味着同一个存储类型下的所有仓位共享同一套作业规则。这也解释了为什么存储类型要按仓储技术来切——高架库和堆放区的上架逻辑本来就不同，前者受货架承重和层高限制，后者受地面面积和堆垛规则限制，放在同一个存储类型下没法配。

预定义类型可以直接拷贝到自己的仓库号下使用，然后按公司实际情况做适当修改。这个“拷贝再改”的路径值得说一下：它比从零建要稳，因为一张白纸建出来的存储类型，很容易漏掉某个不起眼但影响很大的参数。但拷贝也有坑，就是容易把别人场景下的默认值一起带过来，尤其是那些和物理尺寸相关的参数，不改就会出问题。

3.3 存储分区：系统为什么强制你至少建一个

Storage Section 存储分区是存储类型下面的一个细分组织结构，定义是：一些具有共同入库管理特性的仓位的集合。

这里有个反直觉的强制规则：WM 系统要求必须为每一个存储类型至少定义一个存储分区。哪怕你觉得完全没必要细分，也得建一个。只建一个分区，实际上相当于没有对存储类型进行细分，这时候存储分区和存储类型是一对一的关系。

为什么要有这条强制规则？我的理解是，它把“是否细分”这个决策从“配不配”变成了“配几个”。如果允许零个分区，那么所有涉及分区的代码路径都要处理空值分支，配置界面也要处理“未定义”状态，复杂度会扩散到整个系统。强制至少一个，等于让分区这个概念在所有地方都恒成立——一对一的时候它是个透传层，一对多的时候它是个真实的分割层，下游逻辑不用关心是哪种情况。这是典型的用一点冗余换全局简化的设计。

还有一条约束更关键：存储分区里不能定义任何控制参数，这些控制参数通常是从存储类型传递下来的。所以分区只负责“划范围”，不负责“定规则”。规则在存储类型上，范围在分区上。

注意：分区只承载范围，不承载规则。想让某个分区有不一样的上架逻辑，改分区是没用的，得回到存储类型这一级，或者换用别的控制手段。

3.4 分区的划分维度：重量、周转频率、组合标准

分区的划分方法比较灵活，材料给了三种层次的例子。

按重量划：底层重物分区、中层次重货物分区、高层轻型货物分区。这是最贴近物理现实的切法，因为货架的承重能力本来就是按层递减的。这种切法的好处是规则硬、不容易出错，坏处是如果你的货物重量分布很均匀，切了也白切。

按周转频率划：快速移动货物分区、缓慢移动货物分区。这种切法的目标是缩短拣货路径，快货放在靠近出口或者通道的位置。它依赖的是历史出入库数据，所以划分之前得先有数据积累，拍脑袋切出来的快慢区往往和实际不符。

组合标准：快速移动重型货物分区、快速移动轻型货物分区、缓慢移动重型货物分区、缓慢移动轻型货物分区。两个维度交叉，出来四个区。维度的组合一层层加下去，分区数量会指数级膨胀，管理成本也跟着涨。

材料里有一句话值得反复读：存储分区的定义一定要有目的性和实际意义，通常存储分区集中在同一个物理区域。这后半句是硬约束——分区必须在物理上连续。如果你把一层的两个角落划成同一个分区，中间隔着一大片别的区域，那这个分区在物理上就是不成立的，叉车作业时根本没法按区作业。

还有一条容易被忽略：通常存储类型和存储分区是一对多的关系。存储分区主要设计用来实现入库仓位定向选择，所以它的存在意义是服务于上架策略的。如果一个分区对上架决策没有任何影响，那它就是纯粹的负担。

4. 拣货区与仓位：出库侧的平行作业和最小空间单位

4.1 拣货区是存储分区的镜像，但一个必填一个可选

Picking Area 拣货区的定义，材料用了“与存储分区意义相反”这个说法：它是一些具有共同出库拣货管理特性的仓位的集合，协助实现简单有效的出库策略。

把两者对着看，差异非常清晰：

拣货区的实际用途，材料说得很具体：交货单中的所有行项目可以打印在一张拣货单上，如果定义了几个拣货区，系统就可以根据拣货区不同自动把拣货单分拆成几张。这个拆分是后台配置的，也可以不自动拆分。

拆分的意义在于平行作业。一个仓库如果划了几个拣货区、归不同的人管，拣货单自动按区分拆之后，几个人可以同时开工，发货流程整体加快。这是把组织结构上的分工直接映射到单据流上——不用人工分单，系统按仓位所属的拣货区自动切。如果没开这个配置，拣货单还是一整张，一个人从头拣到尾，分区就白划了。

4.2 仓位是主数据，不是组织结构

Storage Bin 仓位的定义：存储类型通常由很多个细分的存储单元构成，这些细分的存储单元称为仓位，仓位是仓库管理最小的空间单位。仓位信息描述的是某一个仓库内某一货物将要存放或者已经存在于的某个位置。

材料里有一句话是整篇里最有分量的一句：在 SAP WM 中，仓位作为主数据存在，而不是仓库内部的组织结构。

这个定位差别带来一连串后果。组织结构是配置对象，改动要走配置传输，影响面大、审批链长；主数据是业务对象，可以按需批量创建、单独维护、批量导出导入。仓位做成主数据，意味着一个真实仓库里成千上万个格子可以批量生成，可以挂独立的属性，可以单独冻结或解冻，而不用动配置。

仓位的命名通常做成坐标值，比如 01-02-03，首两位表示货架编号，中间两位代表列号，后面两位代表层号。这个顺序不是固定的，也可以定义中间两位是层号、后面两位是列号。还可以省略分隔符，材料对这个取舍说得很直白：省略分隔符可以减少 WM 作业中仓位的输入信息，但是增加了识读的难度，需要综合权衡。

这个权衡在实际作业里是要付代价的。手输 010203 比输 01-02-03 少敲两个字符，但在纸质拣货单上、在口语沟通里，010203 到底是 01-02-03 还是 01-20-3，很容易读错。位数一多，这种歧义就变成了找错货的直接原因。仓位可以用英文字母、数字和字符混合定义，这给了灵活性，但也让格式校验变得更依赖约定而不是系统强制。

从数据结构上看，一个仓位由仓库号、存储类型、仓位号三段唯一确定，存储分区是挂在仓位上的一个属性字段。用一段示意查询能看清楚这个层级：

-- 仓位主数据：仓库号 + 存储类型 + 仓位 唯一确定一条记录 -- 存储分区是仓位上的属性字段，不是独立的一层键 SELECT lgnum, -- 仓库号 Warehouse Number lgtyp, -- 存储类型 Storage Type lgpla, -- 仓位 Storage Bin lgber, -- 存储分区 Storage Section maxle -- 最大载重量 Maximum weight FROM lagp WHERE lgnum = '001' -- 先按仓库号收敛 AND lgtyp = '001' -- 再按存储类型收敛 AND lgber = '01'; -- 最后按分区筛一层

这段查询的三个过滤条件正好对应三层收敛：仓库号圈定管理单元，存储类型圈定区域，存储分区圈定区段。注意存储分区是作为过滤条件出现的，不是作为键的一部分——这印证了它“划范围”的定位。最大载重量这类容量属性直接挂在仓位记录上，说明容量判断的粒度是单个格子，不是整个区域。

4.3 仓位属性：容量、防火分区和仓位类型

仓位作为主数据，可以挂的属性和材料里点到的有这几项：

• Maximum weight 最大载重量
• Total capacity 总能力（没有单位的纯数字）
• Fire containment section 防火分区
• Storage bin type 仓位类型

这四项里，前两项是容量类的，第三项是安全类的，第四项是作业策略类的。

容量类属性的作用是给上架搜索提供约束。系统在找一个空位放货的时候，得知道这个格子装不装得下——最大载重量管重量，总能力管体积或者件数。这里有个细节要留意：总能力是没有单位的纯数字。这意味着它到底代表托盘数、箱数还是件数，完全靠实施时约定。同一个仓库里如果不同区域填了不同口径，容量判断就会失真，而这种失真在系统层面是看不出来的，它不会报错，只会让搜索悄悄选错位置。

防火分区属于安全合规属性。同一防火分区内的仓位在火灾风险上是绑定的，存储危险品时这条尤其重要——系统可以据此限制同一分区内的危险品存量。

仓位类型 Storage bin type 是作业策略属性。材料里说：在仓库入库策略中，结合仓位类型、托盘类型可以实现灵活多变的入库方式。这句话点出了一个组合拳——单看仓位类型只是给格子分类，单看托盘类型只是给载具分类，两者一交叉，就能表达“这种托盘只能进那种格子”这样的规则。

4.4 用搜索顺序替代复杂分区：一种更轻的上架控制

材料里有一段来自实际项目的经验，值得单独拎出来：用托盘的仓位搜索顺序来影响入库方向，从而避免定义复杂的存储分区。

这句话背后是一组手段的对比。控制上架方向有两条路：

第一条路是组织结构路线——多划存储分区。想要货往东边走，就划一个东区分区；想要重货往下走，就按层划分区。这条路直观，但代价是分区数量会随着规则数量增长，而且分区是组织结构，改起来重。

第二条路是主数据加搜索顺序路线——保持分区分得粗，把控制逻辑放到搜索顺序里。搜索顺序是一串按优先级排列的搜索策略，系统从上往下逐条尝试，命中第一个可用仓位就停下。常见的实现思路大致是这样：

# 入库仓位搜索：按维护好的搜索顺序逐条尝试，命中即停 search_steps = [ {"bin_type": "H01", "su_type": "EUR", "section": "01"}, # 最严：仓位类型+托盘类型+分区全匹配 {"bin_type": "H01", "section": "01"}, # 放宽托盘类型 {"bin_type": "H01"}, # 再放宽分区，只剩仓位类型 ] for step in search_steps: bin = find_free_bin(storage_type="001", **step) # 在存储类型 001 下找空位 if bin: place_goods(bin) # 第一个命中的可用仓位就是最终落位 break

这段逻辑的关键在顺序，不在过滤条件本身。第一步要求仓位类型、托盘类型、分区三者全匹配，等于把“标准托盘进高架区 01 分区”这个最理想的落位先试一遍；没找到就放宽托盘类型，允许其他载具进来；再没找到就只剩仓位类型，范围放到整个高架区。通过调整这几步的先后和组合，可以相当精细地引导入库方向，而且不用新增任何一个存储分区。

代价是这套逻辑不如分区直观。分区划错了，看一眼仓库平面图就能发现；搜索顺序配错了，得逐条核对每一步的命中情况，而且它的效果依赖主数据质量——仓位类型字段填错一个，整条搜索链的走向就变了。这就是典型的把复杂度从组织结构挪到主数据上，灵活性换来了维护成本。

5. 避坑与排查：仓储主数据里最容易翻车的五处

5.1 只建了一个存储分区，上架策略像是没生效

现象：按重量分层配好了上架策略，重货应该进底层，实际却上了高层，策略看起来完全没起作用。

原因：存储分区才是实现入库仓位定向选择的手段。整个存储类型只建一个分区，等于没有提供任何可以区隔的信息，策略再精细也没有落点。存储类型这一级的控制参数管的是整个类型的作业规则，管不到层与层之间的差别。

解决：物理上确实存在承重差异的，按层建分区，让底层、中层、高层各自成为独立区段。如果只是想让入库方向有倾向、不想动组织结构，可以改用仓位类型加托盘类型的搜索顺序来控制，第 4.4 节那条路更轻。

5.2 仓位坐标省了分隔符，拣货时读错位

现象：仓位定义成 010203 这种无分隔符格式，纸质拣货单上手写传递时，操作员按 01-02-03 去找，实际仓位是 01-20-3，找错货架。

原因：省略分隔符确实减少了输入量，但识读难度上去了。纯数字串没有视觉锚点，位数一多，人眼和口头沟通都容易切错位置。

解决：如果输入量不是瓶颈，保留分隔符。如果必须省，就固定位宽并强制补零，同时在打印和拣货环节按固定位切分后补回视觉分隔——把识读负担从人转移到单据格式上。

5.3 建了拣货区却没开拆单，平行作业落空

现象：仓库按人员分工划了三个拣货区，期望拣货单自动分成三张并行作业，实际出来的还是一整张单子，一个人从头拣到尾。

原因：按拣货区自动拆分拣货单是后台配置项，系统允许拆也允许不拆。建了拣货区只是提供了拆分依据，拆不拆是另一回事。

解决：检查后台的拣货单拆分配置是否打开。同时复核拣货区的划分边界是否和实际人员管理边界一致——如果两个拣货区其实是同一个人管，拆了反而增加单据数量。

5.4 仓库号按建筑拆得太碎，跨楼调拨变成两套账

现象：每栋库房建一个仓库号，结果同一批货在两栋楼之间移动时，库存视图分裂成两套，报表对不上，跨库调拨走的是完全不同的处理路径。

原因：仓库号的定位是管理单元，不是建筑编号。同一个厂区内的多栋建筑，只要仓储策略、人员归属、作业节奏是一套，就该合在一个仓库号下作为仓库联合体管理。

解决：按地理距离和组织归属重新评估边界。同一厂区的一般用一个仓库号；真正隔得远、运输周期不受控的，才拆成独立仓库号。拆分决定要在上线前想清楚，因为仓库号上面挂着计量单位和跨模块接口，后期调整成本很高。

5.5 总能力是个纯数字，口径不统一就失真

现象：仓位容量判断时灵时不灵，明明看起来还有空间的仓位，系统判定放不下；或者反过来，货塞进去了但实际已经超容。

原因：总能力字段是没有单位的纯数字。A 区的人按托盘数填，B 区的人按件数填，系统在比较时不知道单位差异，只做数值比较。这种失真不会报错，只会让搜索悄悄选错位置。

解决：全仓库统一容量口径并写进主数据维护规范。如果不同区域的存储形态差异太大，宁可拆成不同的存储类型分别定义口径，也不要在一个类型里混填。

6. 设计取舍：柔性放在主数据层，代价落在哪里

把这几层拆完，会发现 WM 在控制手段的分布上有一条清晰的分界：跟物理结构绑死的东西放组织结构，跟货品和载具绑定的东西放主数据。

存储类型和存储分区是组织结构。它们描述的是仓库长什么样——哪里是高架、哪里是堆放、哪一段承重强。这些东西一旦建成，几年内不会变，所以值得走配置、走审批。仓位和仓位类型是主数据。它们描述的是具体格子和格子的属性，会随着业务调整不断新增、冻结、改属性，所以必须是主数据，能批量维护。

真正体现设计取舍的，是第 4.4 节那条路：把上架方向的控制逻辑从分区挪到搜索顺序。这个选择的收益很明确——不用为了每一条新规则新增一个分区，组织结构保持稳定，规则调整只动配置。但代价同样明确：系统的行为不再能从仓库平面图上一眼看出来，排查问题得逐条追搜索序列，而且效果高度依赖仓位类型、托盘类型这些主数据字段的准确性。

我一般会用一个判断标准来选路：这条规则会随货品变化吗？会，就走主数据加搜索顺序；不会，只跟建筑结构有关，就走分区。承重分层是建筑属性，不会因为换了一批货就变，适合分区；某类托盘只能进某类货架，这是载具属性，会随着包装方案调整，适合搜索顺序。两者混用也没问题，但要清楚每条规则挂在哪一层，否则出问题时根本不知道该查哪儿。

验证方法其实不复杂：拿一批典型货物跑一遍完整的上架流程，看落位结果是否符合预期，再故意把某个仓位类型字段改错，看搜索链在哪一步断掉。后者比前者更有价值，因为它能暴露出你对搜索顺序的理解偏差。

血泪经验是，我早年在一个项目里为了图省事，把本该用搜索顺序解决的规则全堆成了存储分区，结果分区数量膨胀到几十个，后来业务调整包装方案，光改分区就花了两个星期，还得重跑一遍全量主数据。从那以后我每次配存储类型，都强制先把规则列一遍，逐条标注它属于建筑属性还是货品属性，再决定落在哪一层。这套习惯帮我省掉的返工，比任何配置技巧都多。希望帮到你。

这份资料把 WM 里从仓库号到仓位的整条组织链和中英文对应关系梳理得很完整，上面这些机制讨论都是围绕它展开的。想要拿到原始文档逐条对照着看，按页面上的获取方式取用即可。

本文还有配套的精品资源，点击获取