ResNet18 CIFAR-10小图训练：结构适配、调参与避坑指南

简介面向深度学习入门与图像识别实践者的 PyTorch 项目包围绕 ResNet18 在 CIFAR10 十类彩色小图上的训练与评估展开可用于理解残差块、短路连接、归一化与随机裁剪、水平翻转等数据增强以及交叉熵损失、权重衰减和学习率调度等关键环节。压缩包共 26 个文件约 341.16MB包含 Python 训练与测试脚本、已保存的模型权重、CIFAR10 数据分片及部分预测效果图兼顾代码复现、结果对照与快速验证目录中还将模型定义、训练入口和评估入口分开组织便于按模块阅读。已有1390人学习下载。读者可据此跑通从数据预处理、网络搭建、训练监控到测试评估的完整流程观察训练集与验证集精度变化以排查过拟合也可直接加载权重进行推理适合课程实验、毕业设计原型和卷积网络入门练习。1. 一个 32×32 的小图任务为什么总卡在 93% 精度CIFAR-10 上的 ResNet18 是图像识别里被复现最多的一段 pytorch 深度学习代码也是最容易被“跑通即结束”糊弄过去的一段。很多人第一次训练出来的 top-1 停在 88% 到 91%加个 cosine 也上不去于是开始怀疑数据增强、怀疑随机种子甚至怀疑显卡玄学。真相往往很朴素模型照搬了 ImageNet 的 7×7 大卷积核加 maxpool32×32 的输入过完 stem 只剩 8×8后面三个 stage 的下采样把信息压得没有多少了。ResNet18_CIFAR10.rar 这个包解决的就是这一层问题把 ResNet18 针对小分辨率输入做结构适配配上 CIFAR-10 的归一化参数、增强策略、训练与验证循环、指标统计和导出脚本放在一套能直接跑起来的工程里。适合两类人——刚学完卷积想在真实数据上看到曲线的以及手里有自己小图数据集想拿它当 baseline 的。2. 数据管道把 CIFAR-10 的 mean/std 和增强顺序钉死2.1 解压后的第一件事是确认三件事而不是急着训练拿到压缩包我一般不会立刻python train.py而是先把目录看一遍入口脚本在哪、模型定义是不是单独一个文件、数据缓存目录是不是可写的相对路径。这三件事决定后面调参时能不能快速定位问题。CIFAR-10 的数据集本身只有 170MB 左右第一次运行会通过 torchvision 自动落到./data如果你的运行目录在只读挂载点或者容器里没配好 volume第一次跑就会在下载那一步翻车报的却是网络错误很容易被误导到别的地方去。依赖这块常见做法是单独建虚拟环境把关键库锁在同一个大版本区间里避免 torch、torchvision、numpy 之间出现 ABI 对不上的问题。下面这份 requirements 是我一般在复现这类小图任务时用的写法版本给范围而不是死锁方便在不同机器上装# 建议在虚拟环境里安装别混进系统 Python python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate pip install torch2.0 torchvision0.15 --index-url https://download.pytorch.org/whl/cu118 pip install numpy tqdm tensorboard pillow这段命令的关键点不在版本号本身而在两条一是 torch 和 torchvision 尽量从同一个索引源装避免 CPU 版和 CUDA 版混装导致torch.cuda.is_available()返回 False 却看不出原因二是不把torch写进一个泛化的requirements.txt里随手pip install -r因为在没有 GPU 的机器上它默认拉 CPU 轮子等到训练时才发现速度慢十倍。装完先跑一句校验确认设备、版本、cuDNN 都对得上import torch, torchvision print(torch:, torch.__version__) print(torchvision:, torchvision.__version__) print(cuda available:, torch.cuda.is_available()) print(device count:, torch.cuda.device_count()) print(cudnn:, torch.backends.cudnn.version())参数说明torch.cuda.is_available()为 False 时不要急着改代码先确认驱动和轮子是否匹配device_count用来决定是否要上DataParallel还是DistributedDataParallel——CIFAR-10 这个量级单卡完全够多卡反而会因为 batch 变小拖慢收敛。cudnn.version()返回 None 通常意味着装的是 CPU 版。2.2 归一化参数别抄 ImageNet增强顺序也别乱CIFAR-10 是 32×32 的彩色小图直接用 ImageNet 的mean(0.485, 0.456, 0.406)、std(0.229, 0.224, 0.225)会让输入分布偏掉一点虽然不至于训崩但前期 loss 下降会明显更抖。这套数据集的像素统计常用值是参数通道顺序常用取值说明meanR, G, B0.4914, 0.4822, 0.4465全体训练集逐通道均值stdR, G, B0.2470, 0.2435, 0.2616逐通道标准差输入尺寸-32×32不做 resize只做 padding 后随机裁类别数-10飞机到卡车训练集和测试集必须用同一组 mean/std这一点在老代码里经常被写错——训练时归一化了、验证时忘了准确率会莫名其妙掉几个点而且没有任何报错属于典型的黑匣子问题。增强顺序上我的习惯是RandomCrop(32, padding4)放在RandomHorizontalFlip()之前先平移再翻转这样翻转后的图像边缘填充区域分布更自然ToTensor()一定在几何增强之后、Normalize()之前顺序错了会直接报维度错误或者把归一化作用在 0-255 上。import torchvision.transforms as T CIFAR_MEAN (0.4914, 0.4822, 0.4465) CIFAR_STD (0.2470, 0.2435, 0.2616) train_tf T.Compose([ T.RandomCrop(32, padding4), # 先四周补 4 像素再随机裁回 32等价于平移增强 T.RandomHorizontalFlip(p0.5), # 水平翻转CIFAR 里飞机/汽车翻转后语义不变 T.ToTensor(), # HWC uint8 - CHW float值域压到 [0,1] T.Normalize(CIFAR_MEAN, CIFAR_STD), # 逐通道减均值除标准差 ]) test_tf T.Compose([ T.ToTensor(), T.Normalize(CIFAR_MEAN, CIFAR_STD), # 必须与训练集完全一致 ])逻辑说明RandomCrop的padding4是这类小图任务的常用配置padding 太大比如 8会让有效内容占比过低模型学到大量黑边太小则增强强度不够200 epoch 内很容易过拟合到训练集。p0.5是翻转概率的默认值如果你的数据集里左右语义不对称比如文字方向敏感这个值必须调成 0 或者去掉这一项。Normalize放在最后是为了让前面的几何变换作用在原始像素上避免插值运算在归一化后的负值区间里产生额外偏差。2.3 DataLoader 的四个参数里num_workers 最容易背锅DataLoader看起来只有几个参数实际调起来问题最多。batch_size在单卡 8GB 显存下ResNet18 32×32 输入给到 128 一般没问题给到 256 也能跑但要配合学习率缩放shuffleTrue只对训练集开验证集开了会让指标曲线抖动pin_memoryTrue只有在 GPU 训练时才有意义它把 batch 提前放进锁页内存减少 H2D 拷贝的等待。num_workers是最玄学的一个。设 0 表示在主进程里读数据调试时最稳设 4 到 8 在 Linux 上通常能明显提速设成 CPU 核数反而可能因为进程调度开销变慢在 Windows 上还容易直接卡死或者报BrokenPipeError。我的血泪经验是先在num_workers0下把整个 epoch 跑通确认数据增强没有异常再逐步往上加每次加 2 观察吞吐。from torch.utils.data import DataLoader from torchvision.datasets import CIFAR10 train_set CIFAR10(root./data, trainTrue, downloadTrue, transformtrain_tf) test_set CIFAR10(root./data, trainFalse, downloadTrue, transformtest_tf) train_loader DataLoader( train_set, batch_size128, shuffleTrue, num_workers4, pin_memoryTrue, drop_lastTrue, # drop_last 避免最后一个不完整 batch 影响 BN ) test_loader DataLoader( test_set, batch_size256, shuffleFalse, num_workers4, pin_memoryTrue, )参数说明drop_lastTrue在训练集上打开是为了避免最后一个 batch 只剩几个样本时 BatchNorm 的统计量估计偏差过大验证集不设drop_last否则最后一批样本会被丢掉算出来的准确率不是全集上的。验证集的batch_size可以比训练集大因为不需要存梯度显存占用小得多能加快评估速度。提示num_workers大于 0 时如果报RuntimeError: DataLoader worker (pid xxx) is killed by signal先看是不是容器内存限制太小每个 worker 都会复制一份数据集索引8 个 worker 在小内存机器上足够把 OOM killer 触发。3. ResNet18 适配小图改 stem 而不是改 stage3.1 原版结构在 32×32 上到底损失了什么标准 ResNet18 的第一层是Conv2d(3, 64, kernel_size7, stride2, padding3)紧跟MaxPool2d(kernel_size3, stride2, padding1)。这两步叠加输入分辨率直接除以 4。224×224 的 ImageNet 图像过完还剩 56×56很合理但 32×32 的 CIFAR 图像过完只剩 8×8然后 layer1 保持 8×8、layer2 降到 4×4、layer3 降到 2×2、layer4 降到 1×1最后一个 stage 的特征图只有 1×1空间信息几乎被压平了。这不是“能不能跑”的问题是“能跑但学不到东西”的问题。更麻烦的是 7×7 的大卷积核在 32×32 上覆盖了接近四分之一的画面感受野过大边缘和纹理特征被过度平滑。所以针对 CIFAR 这一类小图任务业界通用的改法是换掉 stem把 7×7 stride 2 换成 3×3 stride 1同时去掉紧跟的 maxpool让第一层输出保持 32×32后续 stage 的下采样节奏就恢复正常了。改完之后各 stage 的输出尺寸是 32 → 32 → 16 → 8 → 4最后是 4×4×512 的特征图再接全局平均池化空间信息保留得充分得多。参数量上会略增一点3×3×3×64 对比 7×7×3×64其实还少了但计算量分布更均匀收敛曲线明显更平滑。3.2 一个 cifar_stem 参数把两套结构装进同一个类实现上有两种写法一种是从头写一个 CIFARResNet另一种是继承torchvision.models.ResNet只替换conv1和maxpool。后者更省事也不容易把 BasicBlock 的下采样逻辑写错。我一般会加一个cifar_stem开关同一个类既能加载 ImageNet 预训练权重做迁移也能从零训练小图版本import torch.nn as nn from torchvision.models import resnet18 class ResNet18CIFAR(nn.Module): def __init__(self, num_classes10, cifar_stemTrue, pretrainedFalse): super().__init__() # 先按标准结构建网weightsNone 表示随机初始化 self.backbone resnet18(weightsIMAGENET1K_V1 if pretrained else None) if cifar_stem: # 替换 stem3x3 stride1输出保持 32x32 self.backbone.conv1 nn.Conv2d( 3, 64, kernel_size3, stride1, padding1, biasFalse ) # 去掉 maxpool用 Identity 占位保证 state_dict 结构清晰 self.backbone.maxpool nn.Identity() # 分类头换成 10 类CIFAR-10 没有 1000 类 in_features self.backbone.fc.in_features self.backbone.fc nn.Linear(in_features, num_classes) def forward(self, x): return self.backbone(x)逻辑说明biasFalse是因为紧跟其后的 BatchNorm 会吸收偏置项留着纯属浪费参数还会让 BN 的 β 和卷积 bias 产生冗余。把maxpool换成nn.Identity()而不是直接del是为了让state_dict的键名保持完整后面加载权重或者做 EMA 的时候不会因为层数对不上而报错。pretrainedTrue时要注意ImageNet 权重和 CIFAR stem 的形状是冲突的conv1换掉之后那部分权重会被跳过实际只有 layer1 到 layer4 能用上这一点在迁移小数据集时值得权衡。3.3 参数量、感受野和 BN 的连带影响改完 stem 之后整个网络的参数量和计算量分布会变。粗略算一下原版 conv1 是 7×7×3×64 ≈ 9.4K 参数新版是 3×3×3×64 ≈ 1.7K少了约 8K但去掉 maxpool 之后layer1 的输入特征图从 8×8 变成 32×32layer1 两个 BasicBlock 的激活值显存占用涨了 16 倍。这是很多人改完 stem 发现显存不够的直接原因不是模型变大了是中间激活变大了。配置conv1 输出layer4 输出单卡 8GB 最大 batch估原版 7×7 maxpool8×81×1512 以上cifar_stem 3×3无 maxpool32×324×4128~256这张表只是量级参考实际能开多大还取决于是否用混合精度、是否开了torch.backends.cudnn.benchmark。如果显存吃紧优先降 batch 而不是把 stem 改回去因为小图上改回原版结构带来的精度损失远比 batch 变小严重。BatchNorm 这块也有连带影响。去掉 maxpool 之后第一层 BN 看到的样本数没变但空间位置从 8×8 变成 32×32统计量的估计其实更稳了。不过如果 batch 降到 32 以下BN 的 running_mean/running_var 会开始抖验证集准确率出现明显波动。这种情况常见做法是改用nn.GroupNorm或者SyncBN但在这个任务量级上更简单的处理是把 batch 保持在 64 以上或者用梯度累积凑等效 batch。注意加载 ImageNet 预训练权重时conv1形状不匹配会触发警告并被跳过如果只看日志末尾的 “missing keys” 很容易忽略。加载完建议手动打印一次conv1.weight.shape确认。4. 训练循环学习率、调度器和混合精度的组合拳4.1 SGD 加 cosine 是这类任务的稳妥起点CIFAR-10 上 ResNet18 的优化器选择其实没那么多花样。Adam 前期收敛快但最终精度通常比调好的 SGD 低半个到一个点SGD momentum 0.9 weight_decay 5e-4 是复现文献里最常见的组合。学习率给 0.1batch 128配合 cosine 退火到接近 0200 个 epoch 基本能到 94% 以上如果用 OneCycleepoch 数可以压到 50 左右适合调参阶段快速验证想法。权重衰减这里有个细节不要把 BN 的参数和 bias 一起加进 weight_decay否则 BN 的 γ 会被往 0 拉训练后期表现会变差。常见做法是把参数分成两组只对卷积和全连接权重做衰减import torch def build_optimizer(model, lr0.1, wd5e-4, momentum0.9): decay, no_decay [], [] for name, p in model.named_parameters(): if not p.requires_grad: continue # BN 的 weight/bias 和所有 bias 不做 weight decay if p.ndim 1 or name.endswith(.bias): no_decay.append(p) else: decay.append(p) return torch.optim.SGD( [{params: decay, weight_decay: wd}, {params: no_decay, weight_decay: 0.0}], lrlr, momentummomentum, nesterovTrue, )参数说明p.ndim 1能一次性筛掉 BN 的 γ/β 和所有 bias因为卷积核至少是 4 维、全连接权重是 2 维。nesterovTrue在 SGD 上是几乎零成本的提升通常能带来零点几个点的收益没有理由不开。学习率 0.1 对应 batch 128如果 batch 翻倍lr 也大致翻倍这是线性缩放经验法则但在加 warmup 的情况下要重新调。调度器用 cosine 的话通常前 5 个 epoch 加 warmup避免一开始 lr 太大把 BN 的统计量带偏from torch.optim.lr_scheduler import CosineAnnealingLR, LinearLR, SequentialLR def build_scheduler(optimizer, epochs200, warmup5): warm LinearLR(optimizer, start_factor0.1, total_iterswarmup) cosine CosineAnnealingLR(optimizer, T_maxepochs - warmup, eta_min1e-5) return SequentialLR(optimizer, schedulers[warm, cosine], milestones[warmup])start_factor0.1表示 warmup 起点是基准 lr 的十分之一逐步线性升到 1.0。eta_min1e-5给一个下限避免 cosine 末端学习率过小导致后期几乎不更新也有人直接设 0差别不大但如果中途要 resume 训练非零下限更好接。4.2 训练与验证循环里指标算错比模型训崩更常见一个 epoch 的循环看起来模板化实际有三个地方容易错loss 的累加方式、准确率的计算范围、model.train()/model.eval()的切换位置。loss 要用item()乘以当前 batch 的实际样本数再加总最后除以总样本数直接用 batch loss 求平均在最后一个 batch 不满时会偏。准确率要在torch.no_grad()里算且记得.eval()否则 BN 会继续用当前 batch 的统计量验证指标会比真实值抖。import torch from tqdm import tqdm def run_epoch(model, loader, criterion, device, optimizerNone, scalerNone): is_train optimizer is not None model.train(is_train) # 关键训练/评估模式切换 total_loss, total_correct, total_num 0.0, 0, 0 pbar tqdm(loader, desctrain if is_train else eval, leaveFalse) for imgs, labels in pbar: imgs, labels imgs.to(device, non_blockingTrue), labels.to(device, non_blockingTrue) with torch.set_grad_enabled(is_train): with torch.autocast(device_typecuda, dtypetorch.float16, enabledis_train): logits model(imgs) loss criterion(logits, labels) if is_train: optimizer.zero_grad(set_to_noneTrue) # 比 zero_grad() 省一次写零 scaler.scale(loss).backward() scaler.step(optimizer) scaler.update() # 指标按样本数加权避免最后一个不满 batch 拉偏 bs labels.size(0) total_loss loss.item() * bs total_correct (logits.argmax(1) labels).sum().item() total_num bs pbar.set_postfix(lossf{total_loss/total_num:.4f}, accf{total_correct/total_num:.4f}) return total_loss / total_num, total_correct / total_num逻辑说明model.train(is_train)一行同时处理训练和评估两种模式比手动写 if/else 少出错。set_to_noneTrue在近几年的 torch 版本里是推荐写法把梯度置为 None 而不是零张量省一次显存写入。混合精度只在训练时开评估时用 fp32 更稳因为验证集通常不大速度差可以忽略但数值稳定性更好。autocast只包住前向和 loss 计算反向由scaler.scale(loss).backward()处理这个顺序不能颠倒。4.3 混合精度不是开了就更快得看卡和算子AMP 在 Volta 架构之后的卡上收益明显在更老的卡上可能反而变慢因为缺少原生 fp16 算力。判断方法很直接跑两个 epoch 对比耗时如果 AMP 没有带来 20% 以上的提速就关掉别为了“看起来先进”引入额外的数值风险。另外 AMP 下有几个算子容易溢出比如 softmax 前的 logits 过大、BatchNorm 在某些实现里需要 fp32autocast已经帮你处理了大部分但自定义 loss 里如果手动做了 exp/log得留意。配合 AMP 还要注意梯度裁剪的时机。scaler.unscale_(optimizer)必须在clip_grad_norm_之前调用否则裁的是被放大过的梯度等于没裁scaler.scale(loss).backward() scaler.unscale_(optimizer) # 先还原真实梯度 torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm5.0) scaler.step(optimizer) scaler.update()max_norm5.0是这类任务的常用值CIFAR-10 上梯度爆炸并不常见但加了 warmup 之后个别 batch 仍可能冲高裁剪相当于买一份后悔药。如果真的频繁触发裁剪先去看学习率是不是设大了而不是把 max_norm 往上调。5. 避坑清单五条在复现现场真实发生过的故障5.1 训练准确率 99%验证准确率 70%中间差了 30 个点现象训练集上几乎拟合验证集卡在七成左右不再上涨loss 曲线平滑看不出任何异常。原因最常见的是增强只加在了训练集、但验证集的Normalize参数写成了另一组值或者验证时忘了切换model.eval()BN 一直用当前 batch 的统计量。还有一种隐蔽情况是数据集划分出错训练集和验证集用了同一个CIFAR10(root, trainTrue)实例只是 transform 不同导致验证指标其实是训练集上的。解决先打印两个 loader 各取一个 batch逐通道算均值和标准差确认一致再检查model.training在验证阶段是否为 False。划分问题可以直接比对len(train_set)和len(test_set)CIFAR-10 应该是 50000 和 10000对不上就是路径或参数写错了。5.2 loss 出现 NaN前几个 batch 正常现象训练到第几十个 batch 突然 loss 变 nan之后所有权重都是 nan只能重启。原因按出现频率排第一是学习率过大且没加 warmup第二是 AMP 下某个算子溢出但没开GradScaler第三是数据里混进了异常值比如自己替换数据集时读到了全 0 图像。另外weight_decay加在 BN 参数上也会在中后期放大数值不稳定。解决先把 AMP 关掉跑 20 个 batch如果不再 NaN说明是精度问题检查GradScaler有没有正确step和update如果还 NaN把 lr 降一个数量级验证。长期方案是按 4.1 的方式把 BN 参数从 weight decay 里摘出来并加上梯度裁剪。5.3 num_workers 一开就卡死或报 BrokenPipeError现象num_workers0一切正常改成 4 之后进程挂住或者直接抛BrokenPipeError、RuntimeError: DataLoader worker is killed。原因主进程里在if __name__ __main__之外创建了 DataLoaderspawn 模式下每个 worker 会重新 import 主模块递归创建 loader 直到资源耗尽。Windows 和 macOS 默认用 spawnLinux 用 fork所以同一个脚本在不同系统上表现完全不同。解决把所有训练入口代码放进if __name__ __main__:保护块里包括 DataLoader 的构造。容器里如果还不行先降num_workers到 2再看内存限制每个 worker 都会复制一份数据集索引对象。5.4 加载预训练权重后精度反而更低现象从零训练能到 93%换成 ImageNet 预训练初始化之后只到 90% 出头而且前期 loss 下降很慢。原因换了 stem 之后conv1的形状和预训练权重不匹配那部分被跳过但 layer1 到 layer4 的权重是按 224×224 输入分布学出来的直接套到 32×32 的归一化数据上前几层的特征分布差异很大。加上只解冻全部参数、学习率又给 0.1预训练权重很快被大梯度冲掉等于白加载。解决加载预训练时把 stem 之外的学习率调小比如 0.01或者先冻结 layer1/layer2 训练几个 epoch 再解冻。更彻底的做法是承认这个任务上预训练收益有限从零训练反而更干净ImageNet 权重更适合迁移到分辨率接近的数据集。5.5 验证指标忽高忽低同一个模型两次评估差两个点现象同一个 checkpoint 连续评估两次top-1 准确率能差 1 到 2 个点。原因验证时没有切eval()BN 用 batch 统计量或者验证集 DataLoader 开了shuffleTrue且没有固定种子再或者是用了drop_lastTrue丢掉了一部分样本。解决验证阶段固定model.eval()加torch.no_grad()shuffleFalse、drop_lastFalse。如果还抖检查是否在评估中误开了数据增强——验证集只能做ToTensor加Normalize任何随机变换都会让指标不可复现。6. 收尾前的三件事EMA、混淆矩阵和一次干净的导出训到 94% 上下之后继续调超参的边际收益已经很低了这时候更值得做的是三件“确认工作量”的事。第一件是 EMA指数滑动平均。它几乎不改训练流程只多存一份影子权重在验证时用影子权重评估通常能稳定带来 0.3 到 0.8 个点而且对学习率末端的抖动有抑制作用。实现上记住两件事影子权重不参与梯度更新以及 BN 的 running_mean/running_var 也要一起滑动很多人只平均了卷积权重结果评估时 BN 统计量对不上收益全没了。class ModelEMA: def __init__(self, model, decay0.999): import copy self.ema copy.deepcopy(model).eval() for p in self.ema.parameters(): p.requires_grad_(False) self.decay decay torch.no_grad() def update(self, model): # 权重和 BN 的 buffer 一起滑动缺一不可 d self.decay for e, m in zip(self.ema.state_dict().values(), model.state_dict().values()): if e.dtype.is_floating_point: e.mul_(d).add_(m.detach(), alpha1 - d) else: e.copy_(m)decay0.999对应大约 1000 步的有效窗口200 epoch × 390 step/epoch 的规模下偏保守想更灵敏可以降到 0.998。dtype.is_floating_point那一支是给num_batches_tracked这种整型 buffer 用的直接 copy 更合适。第二件是混淆矩阵。只看总准确率会掩盖类别不均衡CIFAR-10 里猫和狗、鹿和马这两组最容易互相串。跑一遍sklearn.metrics.confusion_matrix把每类的 recall 打出来如果某一类明显低于其他类先去看这类样本的增强是不是过强比如翻转后语义变了而不是盲目加数据。这一步做完你对模型的了解会比盯着一条 accuracy 曲线深得多。第三件是导出。ONNX 导出前一定model.eval()并固定 batch 维度否则动态轴会导致部分推理后端不认导出后用onnxruntime跑一遍同样的输入和 PyTorch 输出做数值比对最大绝对误差应该在 1e-4 量级。如果误差大先查是不是忘了eval()导致 BN 用了 batch 统计。这三件事做完一个 ResNet18_CIFAR10 的复现才算真正闭环训练指标可信、类别表现可解释、模型能被下游消费。我早期图省事跳过混淆矩阵和导出验证结果线上换推理引擎后精度掉了一大截回头查了两天才发现是 eval 模式没切——从那以后我每次训完都强制走一遍 EMA 评估、混淆矩阵和 onnxruntime 数值对齐这三步不管任务多小。希望帮到你。本文还有配套的精品资源点击获取