lvcreate命令详解：从零创建LVM逻辑卷与实战指南-代码聚汇网

lvcreate命令详解：从零创建LVM逻辑卷与实战指南

黑河市all·2026-09-06·阅读 22 GEO检测（免费）

lvcreateLVM逻辑卷管理

|难度：普通|阅读约 38 分钟

1. LVM体系里lvcreate到底解决什么问题

先说一个我经常在面试和社区答疑中遇到的场景：很多人刚接触Linux磁盘管理时，第一反应是用fdisk或者parted直接分区，然后mkfs格式化、mount挂载，一套流程下来也跑得好好的。那为什么还要引入LVM这一层？为什么创建逻辑卷的时候非要用lvcreate这个命令？

核心答案就一句话：LVM把“物理磁盘空间”和“文件系统看到的空间”解耦了。没有LVM时，分区大小是固定的，磁盘满了要么删数据，要么停机加盘重新分区，要么用resize2fs在离线状态折腾半天。有了LVM之后，你在lvcreate创建出来的逻辑卷上格式化文件系统，后续发现空间不够，只需要lvextend配合xfs_growfs或resize2fs在线扩容，完全不中断业务。

lvcreate本身做的事情，是在一个已经存在的卷组（VG）里，按照你指定的方式切割出一块空间，生成一个逻辑卷（LV）。这个LV对上层应用来说就是一块块设备，路径通常是/dev/卷组名/逻辑卷名，你可以把它当成普通分区一样格式化、挂载、跑数据库或者存文件。

这个命令在LVM三板斧PV→VG→LV中处于最后一环：pvcreate把物理磁盘或分区变成物理卷，vgcreate把物理卷聚合为卷组，lvcreate则从卷组里“切蛋糕”。所以用lvcreate之前，前面两步必须已经完成——除非你想顺带练一练pvcreate和vgcreate，否则会直接报错“Volume group not found”。

适合谁来学？如果你是Linux运维、SRE、数据库管理员，或者正在准备Linux相关面试，这篇文章会把lvcreate的常用参数、背后原理、实际坑点和生产环境最佳实践一次讲透。小白也能看，因为我尽量用生活化的类比把每一层概念说清楚。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 创建逻辑卷之前必须确认的事：PV/VG状态与空间核算

2.1 先分清物理卷、卷组、逻辑卷的关系

很多人一上来就敲lvcreate，结果各种报错。我建议养成一个习惯：动手之前先搞清楚当前系统的LVM布局。你可以把物理卷理解成“整块地皮”，卷组是“已经合并在一起的大地块”，逻辑卷则是“从大地块里划出来的一块块宅基地”。三条命令对应三种状态查看：

bash复制pvs          # 查看物理卷
vgs          # 查看卷组，重点看 VFree 列
lvs          # 查看已有逻辑卷

实际输出大致长这样（版本不同可能略有差异）：

bash复制[root@localhost ~]# pvs
  PV         VG        Fmt  Attr PSize  PFree
  /dev/sdb1  data_vg   lvm2 a--  1.99t  1.50t

[root@localhost ~]# vgs
  VG      #PV #LV #SN Attr   VSize  VFree
  data_vg   1   2   0 wz--n- 1.99t  1.50t

这里的关键是卷组的VFree列。lvcreate创建逻辑卷时，空间只能从VFree中划取，绝对不能超过这个值。很多报错“Insufficient free space”就是在这里翻车的。

2.2 空间不够时先扩容卷组

如果VFree已经小于你想分配的空间，别急着调整逻辑卷，先给卷组扩容。方法也很直接：

bash复制# 1. 新磁盘或新分区做成物理卷
pvcreate /dev/sdc1

# 2. 把物理卷加入已有卷组
vgextend data_vg /dev/sdc1

# 3. 再看VFree，空间已经变大了
vgs data_vg

这一步我多说一句：生产环境中，我见过有人在没确认VFree的情况下直接lvcreate，失败后以为是命令写错了，反复检查参数，实际上就是卷组没有空间了。所以任何一次创建逻辑卷之前，vgs都是必查项。

2.3 查看物理卷的PE大小

LVM有个基本概念叫PE（Physical Extent），物理卷上的空间是被切成一个个连续的小块来管理的，就像把地皮切成方块，分配时按块给。PE大小在创建卷组时决定，默认是4MiB，并且卷组一旦创建，PE大小就无法更改。

lvcreate的-l参数和-L参数都跟PE的大小有关系。你甚至可以这样查看当前卷组的PE大小和PE总数：

bash复制vgdisplay data_vg | grep -E "PE Size|Total PE|Free  PE"

输出里会有类似：

bash复制PE Size               4.00 MiB
Total PE              524288
Free  PE              393216

知道PE大小不是为了炫技，而是为了理解-l参数的本质：-l 100表示分配100个PE，也就是400MiB。不同发行版、不同卷组，PE大小可能不同，所以写脚本时如果用了-l，最好先确认PE大小，否则计算出来的容量跟你预期的不一样。

2.4 确认卷组类型对lvcreate的影响

还有个容易忽略的细节：卷组有不同的类型。普通卷组是lvm2，还有一种叫lvm2-thin的卷组，专门用于创建精简配置的逻辑卷（thin pool和thin volume）。你输入vgs的时候，VG那一列的信息可以带上属性：

bash复制vgs --options +vg_attr

输出里的第8个字符如果是t，说明这个卷组带了thin pool相关的能力。基于普通卷组创建的LV是“立即占用空间”的厚卷，基于thin卷组创建的LV则可以在不预分配全部空间的情况下创建。两者在lvcreate的参数上有很大差异，后面的进阶章节会专门讲。

3. lvcreate核心参数逐个拆解：用法背后是设计意图

3.1 容量指定：-L 和 -l 的取舍

这是lvcreate最核心的一组参数，也是新人最容易糊涂的地方。

-L：直接指定容量大小，支持单位。常见写法是-L 10G、-L 500M、-L 2T。它还可以写成-L +10G，表示在逻辑卷当前大小基础上增加10GiB。创建时一般不需要加+。
-l：小写L，指定PE数量或者百分比。写法有-l 100（100个PE）、-l 50%VG（卷组总空间的50%）、-l 100%FREE（卷组所有剩余可用空间）、-l 50%PVS（卷组内所有物理卷总空间的50%）、-l 50%PVS和-l 50%VG的区别在于百分比参照物不同。

我个人的建议是：日常管理和脚本里优先使用-L，因为它直观、可读性强，别人看你的命令一眼就明白你在分配多大的空间。-l适合两种情况：一种是分配全部剩余空间时用-l 100%FREE，一种是写自动化脚本需要按卷组百分比动态分配时。比如你写一个装机脚本，不同机器磁盘大小不同，你想每台机器都把卷组的30%分给某个LV，这时候用-l 30%VG就很聪明，直接用-L反而写死容量不灵活。

-L和-l还有一个使用上的坑位：两者不能同时使用。你敲了-L 10G -l 100%FREE，命令会直接报错，因为LVM不知道你到底想用哪种方式分配。实际工作中我只见过一个人这么写过，原因是他原本想指定大小，后来忘了删掉旧参数。

3.2 命名参数：-n 的逻辑与默认规则

-n指定逻辑卷名称。比如：

bash复制lvcreate -L 100G -n data_lv data_vg

创建出来的块设备路径就是/dev/data_vg/data_lv。这里的命名遵循Linux设备命名习惯，实际指向的是一串dm设备映射。如果省略-n，LVM会自动生成一个名称，比如lvol0、lvol1，这种名字在生产环境里完全没有辨识度，过两周你就不知道这个卷是干嘛的了。

我强烈建议命名时带上业务语义，比如mysql_data、nginx_logs、backup_store。这样后续维护、扩容、脚本调用都省心。要知道一个服务器上可能有好几个卷组，每个卷组里又有很多逻辑卷，良好的命名规范就是运维的隐形资产。

3.3 类型参数：--type 与默认的线性卷

lvcreate默认创建的是线性卷（linear volume），也就是把空间连续地放在一个物理卷上。当你的卷组里有多个PV时，线性卷默认只会使用其中一个PV的空闲空间，直到这个PV的空间耗尽，LVM才会继续使用下一个PV。

听起来似乎没问题，但这里有个性能隐患：如果两个PV的响应速度不一样，线性卷跨PV存放数据时，不同区域的I/O性能会不一致。于是就有了条带卷（striped volume），通过--type striped创建。条带卷会把数据拆分成条带均匀分布在多个PV上，类似RAID 0，可以提升读写吞吐。比如两个PV，每个PV都空闲，你想让一个LV同时利用这两个PV的性能：

bash复制lvcreate -L 200G -n striped_lv --type striped -I 64 -i 2 data_vg

这里的-i 2表示使用2个PV，-I 64表示条带大小是64KiB。具体数值怎么定？条带大小和数据库的I/O特性有关系，如果跑的是OLTP业务、随机读写较多，条带大小可以小一点（32K或64K）；如果是大文件顺序读写，可以设128K或256K。具体没有绝对最优，得结合实际压测结果来调整。

我在生产环境遇到过一个问题：在条带LV上跑数据库，结果发现一个PV的磁盘故障，整个LV直接挂掉。这就是条带的特点——没有冗余，一个PV丢了，数据就全没了。所以条带卷千万别用在重要数据上，除非你有Replication或者备份兜底。

3.4 确认参数：-y 与交互式提示

默认情况下，lvcreate可能会在删除、覆盖或某些特殊操作时弹出确认提示。比如你用lvcreate配合-n创建了一个已经存在的LV名称，它会提示是否覆盖。脚本环境下，这种交互提示会卡住整个自动化流程，所以-y参数就是用来“自动回答yes”的。

不过-y不是所有情况都能跳过——比如创建逻辑卷如果遇到卷组不存在，它不是问你是否创建卷组，而是直接报错退出。所以-y只解决“要不要继续”的交互，不解决“条件是否具备”的问题。

3.5 常用参数速查表

我把日常最常用的参数整理成一个表，方便你写脚本时快速回顾：

参数	含义	示例	说明
`-L`	指定容量	`-L 50G`	直观指定空间大小
`-l`	按PE数或百分比	`-l 100%FREE`	按PE、VG百分比分配
`-n`	逻辑卷名称	`-n mysql_data`	必须加上，便于识别
`-y`	跳过确认提示	`-y`	脚本环境必加
`--type`	指定LV类型	`--type striped`	默认linear
`-i`	条带PV数量	`-i 2`	和--type striped配合
`-I`	条带大小	`-I 64`	单位是KiB
`-p`	设置权限	`-p r`	r为只读，rw为读写
`-r`	自动格式化文件系统	`-r xfs`	需要配合`-L`或`-l`
`-W`	是否启用wiping	`-W y`	默认擦除已有签名，防止误挂载
`-c`	指定chunk大小	`-c 64`	用于thin pool，单位KiB

有必要展开说一下-W。新版LVM在创建LV时，如果检测到对应的PV上存在旧的签名（比如之前是ext4文件系统或者swap格式），会警告并提示是否抹除。有时候你明明创建成功了，但格式化的时候发现报错“找不到文件系统”，就是因为LV的底层设备里还残留了旧签名。这时用wipefs -a清理一下就好。

4. 新手最容易忽略的两件事：-r自动格式化和类型匹配

4.1 -r参数：创建后直接格式化文件系统

有些人对lvcreate的认知还停留在“只负责切割空间”，格式化得自己再跑一遍mkfs。实际上LVM提供了-r参数，可以在创建LV的同时自动做格式化。比如：

bash复制lvcreate -L 100G -n web_data -r xfs data_vg

这条命令创建了100G的逻辑卷，并且直接在LV上格式化为xfs文件系统，一步到位。前提是系统里装了对应文件系统的格式化工具（mkfs.xfs或mkfs.ext4），没装就会报错。

有人说这个功能多此一举，自己跑一遍也没事。但我想强调的是：-r还自带一个隐藏价值——它会帮你自动完成设备节点的注册。在某些系统环境里，创建LV后需要udevadm settle刷新设备节点才能看到/dev/卷组/逻辑卷，-r内部会等待设备稳定后再格式化，从流程上规避了那种“设备还没就绪”的玄学问题。

4.2 文件系统类型匹配的深层逻辑

-r参数虽然方便，但要注意文件系统类型和后续扩容能力的匹配。LVM在线扩容时，xfs只能扩大、不能缩小，ext4则是扩大和缩小都支持。所以你在创建LV并格式化的时候，就要想清楚未来有没有缩容需求。

比如你是一个OpenStack环境的管理员，云主机的系统盘用LVM做底层，就特别依赖lvcreate -r ext4这种方式快速创建和销毁虚拟机磁盘。切片式操作讲究的就是快，手动mkfs多一步不说，还容易漏。用-r可以完全避免这种失误。

5. 从零创建逻辑卷：一套完整的标准操作流程

这里我以一个具体的生产场景为例，带你把全流程走一遍。场景是：服务器新增了两块1TB硬盘（/dev/sdb和/dev/sdc），要从零开始建立LVM并在上面创建两个逻辑卷，一个放MySQL数据，一个放备份文件。

5.1 创建PV和VG

bash复制# 对整块磁盘不做分区，直接建PV
pvcreate /dev/sdb /dev/sdc

# 创建卷组，命名为 data_vg
vgcreate data_vg /dev/sdb /dev/sdc

这里用整块磁盘而不是分区建PV，省去了分区步骤，很多现代环境都这么干。pvcreate执行后，会在磁盘头部写入LVM元数据区域，用pvs验证一下：

bash复制pvs

正常情况下可以看到两块盘都属于data_vg了。

5.2 在卷组中创建逻辑卷

bash复制# MySQL数据卷，分配600G
lvcreate -L 600G -n mysql_data data_vg

# 备份卷，使用剩余所有空间
lvcreate -l 100%FREE -n backup_data data_vg

执行完后，用lvs查看逻辑卷信息：

bash复制lvs

你会看到mysql_data和backup_data两个LV都已经存在，大小各600G和剩余空间。这里有一个值得说的细节：为什么MySQL数据卷用-L 600G而备份卷用-l 100%FREE？因为这个场景中MySQL数据大小是已知的，按需求分配；备份数据则是越多越好，干脆把所有剩余空间都划给备份。

5.3 格式化并挂载

bash复制# 注意这里用的是 /dev/data_vg/mysql_data 这个路径
mkfs.xfs /dev/data_vg/mysql_data
mkfs.xfs /dev/data_vg/backup_data

mkdir -p /data/mysql
mkdir -p /data/backup

mount /dev/data_vg/mysql_data /data/mysql
mount /dev/data_vg/backup_data /data/backup

# 写入fstab实现开机自动挂载
echo "/dev/data_vg/mysql_data  /data/mysql  xfs  defaults  0 0" >> /etc/fstab
echo "/dev/data_vg/backup_data /data/backup xfs  defaults  0 0" >> /etc/fstab

写入fstab时，我建议用UUID而不是设备路径。虽然LVM的设备路径在重启后相对稳定，但万一你做了vgexport、vgimport或者PV替换，设备路径有可能会变。用blkid把UUID查出来写进fstab更稳妥。

5.4 验证整个过程是否成功

bash复制lvs
df -h | grep data

df -h如果能看到两个挂载点，并且大小正确，说明创建成功。如果你想看更底层的块设备映射关系，可以用：

bash复制ls -l /dev/data_vg/

会看到mysql_data和backup_data两个软链接，指向/dev/dm-0和/dev/dm-1之类的设备。这就是LVM映射层的作用。

6. 我在实际运维中遇到的lvcreate报错与排查链路

这一节我想专门说说踩坑，因为很多问题看着五花八门，根源其实就那么几个。调试一个命令就像侦探破案，逻辑得一条线串起来。

6.1 “Volume group not found”是最常见的低级错误

code复制  Volume group "datavg" not found
  Cannot process volume group datavg

排查思路非常直接：

先vgs看看系统里到底有哪些卷组，确认卷组名是不是写错。
用vgscan重新扫描，防止系统刚启动或者LVM元数据没及时加载。
如果卷组确实存在但就是找不到，可能是内核还没识别，跑一下vgchange -ay手动激活。

以前在CentOS 6往CentOS 7迁移时遇到过一种情况：新系统里PV还在，VG信息也完整，但旧系统的VG UUID跟新系统内核缓存冲突。解决方法是先用vgimportclone或者vgcfgrestore恢复元数据，再激活。大部分人在这一步就开始重装系统了，其实没必要。

6.2 “Insufficient free space”不是真的没空间

code复制  Insufficient free space: 25600 extents needed, but only 10000 available

这个报错信息其实已经把答案说了：你要求的PE数超过了VG里Free的PE数。遇到它，按两个方向排查：

用vgs查看VFree，确认当前确实没有足够的空闲空间。注意VFree的单位一般是GiB或者与PE大小相关，和-L参数的单位要统一换算。
如果VG里确实没有空间，按第二节的方法vgextend扩容。

还有一种隐藏情况：空间的碎片化。LVM默认按PE分配时，会尽量保证连续性，如果你的PV上有大量小碎片，即使总Free空间够大，也可能因为找不到足够连续的PE而报错。解决方案是换一个PV作为目标，用-n前面的[PV路径]指定物理卷来分散分配。举例：

bash复制lvcreate -L 100G -n test_lv data_vg /dev/sdc

指定/dev/sdc可以避免LVM自动分配造成的碎片问题。

6.3 “Failed to activate new LV”设备节点刷新失败

创建命令本身执行成功，但激活时失败：

这类问题在容器环境、虚拟化环境里特别常见。排查方向：

先确认系统有没有device-mapper模块，lsmod | grep dm_mod，没有就modprobe dm_mod。
检查/dev/mapper目录是否存在，不存在就手动创建。
用vgscan --mknodes重建设备节点。

我见过最夸张的一次是在一个精简的Docker镜像里，整个/dev/mapper目录都没了，lvcreate创建命令虽然成功，但设备节点根本不生成。重建目录加vgscan --mknodes一下就恢复，问题的本质是容器镜像裁剪过度，少了设备管理相关的目录结构。

6.4 “WARNING: xfs signature detected on /dev/data_vg/test at offset 0”

这不是报错，是警告，LVM在创建LV时检测到底层设备上残留了文件系统签名。如果你忽略这个警告直接格式化，可能看到“mkfs.xfs: /dev/... is mounted or in use”之类的提示，其实根源就是旧签名导致udev误判。

处理方式：用wipefs清理设备上的签名。如果这个LV是新创建的，直接用：

bash复制wipefs -a /dev/data_vg/test

然后再格式化。生产环境你要格外小心，确认这个LV确实是新建的、里面没有需要的数据，才能执行wipefs。

6.5 从一条报错学到的最深一课

有一次半夜被电话叫醒，说一台数据库服务器新加的卷挂载不上。我到现场一看，vgs能看到卷组，lvs也能看到逻辑卷，但mount报“No such device”。用dmesg查看内核日志，发现一条信息——

code复制device-mapper: table: 253:2: linear: Device lookup failed

排查到最后，发现是上层虚拟化平台把一块底层磁盘重新挂载后，PV的识别顺序变了，导致PV里的设备路径指向了不存在的设备。解决办法是用vgreduce --removemissing把失效的PV记录删掉，然后用vgextend重新加入正确的PV。整个过程最关键的教训就是：LVM虽然好用，但它不是万能的，底层设备路径的变化照样会把你坑得很惨。

所以我的建议是，在云环境中，优先用云平台提供的块存储和快照能力；在自建环境中，LVM是利器，但一定要搭配监控、告警和备份策略，不要裸奔。

7. lvcreate的进阶玩法：条带、精简配置与快照

到这里，基础用法已经讲完了，可以聊点进阶的。

7.1 条带卷（striped volume）的创建与适用场景

前面提过条带卷，这里补一个完整示例。卷组里有2个PV，每个PV大小为1TB，想在卷组里创建一个跨两个PV的条带卷：

bash复制lvcreate -L 500G -n stripe_test --type striped -i 2 -I 64 data_vg

执行后lvs显示的大小仍是500G，但实际的I/O会分摊到两个PV上。条带卷适合对单卷吞吐有较高要求的场景，比如视频转码临时目录、大数据分析中间结果。它不适合存档类数据，因为任何一个底层磁盘损坏都会导致整个LV不可用。

7.2 Thin pool与thin volume：逻辑卷超卖的艺术

精简配置（Thin Provisioning）是LVM里很有意思的一个功能。传统的厚卷（thick volume）在创建时就把空间从VG里划走了，会立即占用；精简卷则不同，它先创建一个thin pool（一个底层的空间池），然后从pool里创建多个thin volume，只有真正写入数据时才会占用pool的空间。

创建流程分两步：

bash复制# 第一步：先创建thin pool
lvcreate -L 300G --thinpool data_thinpool data_vg

# 第二步：从thinpool里创建两个thin volume
lvcreate -V 200G -T data_vg/data_thinpool -n vm1_disk
lvcreate -V 200G -T data_vg/data_thinpool -n vm2_disk

最终你创建了两个看起来各有200G的卷，但底层thin pool只有300G，两个卷加起来的逻辑空间是400G，已经“超卖”了。这个特性在虚拟化场景下非常实用——你对所有VM承诺了容量，但实际写入的数据远低于承诺值时，物理磁盘占用非常少。

使用thin pool一定要配监控。因为一旦thin pool满了，所有thin volume都会变成只读或者报错，这在生产环境是灾难性的。我的建议是：给thin pool的监控告警阈值设定为80%，预留20%的缓冲空间用于处理突发写入和安全释放操作。

7.3 快照卷：用lvcreate以几乎零成本拿到一致时间点

LVM快照可能是lvcreate最被低估的能力。快照的创建秒级完成，而且刚创建时几乎不占额外空间——它采用的是CoW（Copy-on-Write）机制：快照创建后，只有原始卷的数据块发生写操作时，才会把旧数据复制到快照区域。

创建一个快照非常直接：

bash复制lvcreate -L 10G -s -n mysql_data_snap /dev/data_vg/mysql_data

这里-s表示snapshot，-L 10G不是快照要立即占用的空间，而是给快照预留的增长上限。快照的容量根据源卷写入频率和持续时间预估，写入越频繁、保留时间越长，需要的快照空间越大。快照满了会怎样？快照会变成无效状态，直接不能用。所以生产环境做快照前，先估算好空间，或者定期用lvs观察快照的Data%使用率。

快照在测试场景格外好用。比如你要升级数据库版本，先打个快照，升级失败后一秒回滚，比备份恢复快得多。

7.4 先规划类型，再敲命令

创建逻辑卷之前先想清楚类型，这是进阶用法和基础用法的核心差异。普通线性卷适合大部分传统业务；条带卷适合高吞吐、可容忍单盘故障的场景；thin volume适合虚拟化和多租户环境；快照是运维操作中的保险丝。在纸上画好LVM拓扑，再敲对应的lvcreate命令，比摸着石头过河靠谱得多。

8. 我的几条铁律：生产环境使用lvcreate的注意事项

最后把这些年实战中总结出来的几条硬经验放在这里，算是给新人的一份“保命手册”。

第一，创建逻辑卷前先检查vgs和pvs，不要凭记忆敲命令。环境是会变的，昨天还有100G空闲，今天可能就被别人占满了，先确认再动手。

第二，命名里带上业务含义。生产环境常有几十个逻辑卷，如果都叫lvol0、lvol1，排查问题时要翻半天。我建议的命名规范是“业务名_用途”，比如mysql_data、nginx_logs、backup_monthly。

第三，重要数据卷前一定先备份再动刀。虽然LVM扩容和创建操作本身相对安全，但你永远不知道下一步会不会遇到底层设备的诡异问题，多一个快照或者备份，半夜就不会被电话叫醒。

第四，创建LV时主动清理旧签名。不管你用不用-r参数，只要看到WARNING提示有旧文件系统签名，先wipefs再继续，避免后续一系列诡异问题。

第五，日常多用lvchange -an和lvchange -ay做开关测试。不要等出了故障才去理解激活机制，先把LV的active/inactive状态切换练熟，对后续故障排查帮助很大。

第六，磁盘性能瓶颈优先用-i和-I解决，而不是盲目加LV。先了解当前I/O是随机还是顺序、单线程还是多线程，再决定要不要条带化。条带化虽然能提升性能，但会降低可靠性，取舍要自己权衡。

lvcreate说到底是LVM体系中一个“承上启下”的命令——上面承接的是pvcreate和vgcreate的空间组织，下面衔接的是mkfs、mount、lvextend、lvreduce、lvremove等后续操作。把它用熟，你对Linux存储管理的掌控力会上一个台阶。

我个人在实际操作中的体会是：学习lvcreate最好的方式不是背参数，而是找一台测试机，把所有参数都试一遍，然后在测试机上故意制造各种错误场景。只有亲手踩过“Volume group not found”的坑、见过“Insufficient free space”的报错、体验过快照翻车的状态，你在生产环境里才能真的心里有底。希望你读完这篇文章后，能自己去实验环境里敲一遍，比记住多少参数都管用。