基于深度学习的电力负荷预测：LSTM模型实战与完整Python实现

简介：本资源是一套完整的基于深度学习的电力负荷预测毕设项目实现，面向计算机、人工智能、自动化及电气工程等相关专业的本科生与研究生，解决短期电力负荷时序建模与高精度预测的实际问题，适用于毕业设计、课程大作业及科研入门实践。压缩包共26个文件，含4个核心Python脚本（如train_univariate.py、model.py）、2个Jupyter Notebook（data_process.ipynb、result.ipynb）、7个Shell调度脚本（支持TCN模型多窗口长度训练）、5张关键流程图与结果可视化图（如TCN.png、ResultTable.jpg），以及requirements.txt、README.md和预处理数据说明等辅助文档，整体大小为64.19MB。已有278人学习下载，项目经答辩评审获98分，代码全部调试通过并附详细文档说明。读者可直接运行复现TCN（时间卷积网络）在REFIT数据集上的单变量负荷预测全流程，掌握数据清洗、VMD分解、滑动窗口构建、模型训练与评估等关键技术环节，具备良好的教学示范性与工程延展性。 电力负荷预测这个东西，做电力行业的不会陌生。不管是电网调度、售电公司做现货交易策略，还是工厂做能源管理，都得靠它来预判未来一段时间要用多少电。传统的时间序列方法比如ARIMA、指数平滑，简单场景下够用，但一旦碰上节假日、极端天气、产业结构调整这些复杂因素，预测误差会被拉得很难看。最近几年，深度学习在这一块几乎是统治级的表现，LSTM、TCN、Transformer这些模型轮番上阵，把预测精度提高了一个档次。

我手上这个项目，主题是“基于深度学习的电力负荷预测研究”，附带完整的Python源码和技术文档。折腾下来，前前后后跑了两个多月，踩了不少坑，也总结了不少经验。这篇就把整个项目从数据准备、模型选型、代码实现到文档撰写全部拆开来讲，给准备做类似课题的朋友一套可以直接上手的完整参考。不管是做课程设计、毕业论文，还是实际工程应用，思路和代码都是通用的，你照着搭一套自己的预测系统完全没问题。

1. 整体设计与技术选型

1.1 电力负荷预测到底在预测什么

先把这个问题的本质说清楚。电力负荷预测，本质上是一个时间序列回归问题，输入过去一段时间的历史负荷数据，输出未来某个时刻的预测值。按预测时长来分，通常有超短期（分钟级到小时级）、短期（未来1到7天）、中期（一个月到一年）这几类。

这个项目做的是短期负荷预测，预测未来24小时的逐时负荷。选这个预测尺度，主要原因是它最贴近实际工程需求——电网调度需要提前一天安排发电计划和机组启停，售电公司需要根据第二天的负荷预测去申报交易电量，误差直接影响真金白银。

这个问题的难点在哪里？电力负荷不是一个稳定的过程，它有几个明显的特性：

• 周期性强：每天的负荷曲线有早高峰、晚高峰，工作日和周末的曲线形态差别很大，春秋季和夏冬季的用电模式也不同。
• 非线性强：气温、湿度、风速这些气象因素对负荷的影响不是简单的线性叠加，比如空调负荷在气温超过某个阈值后会急剧上升。
• 不确定性大：突发性的事件，比如重大活动、临时停电、极端天气，都会造成负荷的剧烈波动。

传统的时间序列模型，比如ARIMA，本质上是线性模型，对周期性和趋势性的建模能力有限。更关键的是，它很难把气温、湿度这些外部变量合理地融合进预测过程中。深度学习的优势就在这里——LSTM这类循环神经网络天然适合处理序列数据，能够学习到负荷数据中复杂的时序依赖关系；同时通过设计合理的输入特征，可以把气象因素、日期类型这些外部信息一并用进去。

1.2 为什么选LSTM而不是Transformer

模型选型这个环节，我试了几种方案，包括LSTM、CNN-LSTM、TCN，也看了Transformer相关的论文。最终主模型用了LSTM，辅助对照用了CNN-LSTM和TCN。这个选择有很实际的理由：

• LSTM是时间序列任务最成熟的选择：从2015年前后开始，LSTM在各种时序预测任务中被广泛验证，技术沉淀够深，排查问题方便。对电力负荷预测这个场景来说，LSTM的门控机制能够有效捕捉负荷序列中的长期依赖关系，比如周周期性——上周一某个时刻的负荷对本周一同时刻的负荷有明显的参考价值。

• CNN-LSTM做了多尺度特征提取：单用LSTM处理长序列时，计算量大、训练时间长。CNN部分先在时间维度上做卷积池化，压缩序列长度，提取局部特征，再交给LSTM做时序建模。这样做的好处是训练更快，而且对负荷序列中短期的波动特征更敏感。

• TCN作为强对照：TCN用膨胀因果卷积实现序列建模，理论上有比LSTM更大的感受野，而且可以并行计算。我实际跑下来，在普通配置的机器上，TCN比LSTM快不少。模型设计的时候，TCN用稍大的网络就能达到和LSTM接近的精度。

为什么不直接用Transformer？Transformer在长序列建模上确实很强，但电力负荷预测不是自然语言处理那种极长序列任务，输入窗口通常是几十到几百个时间步，LSTM完全够用。而且Transformer对数据量的要求更高，小数据集上容易过拟合。我见过不少项目一上来就用Transformer，结果训练时间长、效果还没有LSTM好。

1.3 评估指标怎么定

模型训练完不能只靠眼睛看曲线说“很像”，要量化指标。这个项目用了三个指标：

• MAPE（平均绝对百分比误差）：这个最直观，跟业务方汇报时就直接说“平均误差百分之几”，非技术人员也能听懂。
• RMSE（均方根误差）：对大误差更敏感。电力系统里，峰值时段的预测偏差影响最严重，RMSE能反映出这方面的表现。
• MAE（平均绝对误差）：就是字面意思，单位是千瓦或兆瓦，方便跟负荷量级做对比。

实际算下来，我这边模型在测试集上的MAPE大约是2.3%，RMSE大约是28MW（整个区域峰值负荷在1200MW左右），传统ARIMA的MAPE在5%上下。2.3%这个水平在行业内算是中规中矩的，不少工业级的系统能做到1.5%左右，但作为研究型项目已经能说明深度学习方法的有效性了。

2. 数据是项目的生命线：预处理和特征工程怎么搞

2.1 数据来源和基础信息

训练数据用的是国内某地级市的公开电力负荷数据，时间跨度从2016年1月到2019年8月，采样粒度是15分钟一个点。由于负荷数据发布有延迟，数据集本身存在一定程度的不完整和异常，这正好也符合真实业务场景。对模型来说，数据质量比模型结构更影响最终效果，这句话在负荷预测领域尤其正确。

原始数据的格式大概是这样的，列名我放在下表里：

15分钟粒度的数据，一天就是96个点。如果直接拿来训练LSTM，输入序列长度会比较长，而且15分钟粒度的负荷波动有很多是随机噪声，对预测精度的贡献有限。我先把数据重采样成小时粒度，一天24个点。这个决策的考虑是：短期负荷预测的常用粒度就是小时级，预测未来24小时的逐时负荷，时间分辨率合适，模型输入输出维度也好设计。

2.2 数据清洗的几个坑

数据清洗看起来是脏活累活，但它的重要性怎么强调都不过分。我数了一下这堆数据里有哪些问题：

• 缺失值：大约占总量0.3%，分布在各个时间段。电力数据缺失的原因很多，通信中断、采集设备故障都有可能。
• 异常值：最典型的一种情况是某几个时间点的负荷直接变成0，或者突然跳到正常值的两三倍。真实业务中还有一种常见情况是负荷在某个时段长期保持一个恒定数值不变，这种往往是采集器坏了后的假数据。
• 节假日数据：春节期间的负荷曲线跟平时完全不一致，通常会降到平时的一半以下。

处理策略分别是：缺失值用前后相邻两天的同一时刻均值填充；异常值用箱线图法检测，把超过四分位距3倍的数据点标记出来，用同条件下正常值替换。对于节假日，我没有直接删除，而是作为特征标记。因为模型训练需要见过节假日才能学会节假日的行为模式，但样本量少怎么办？那就需要在损失函数上做文章——对节假日的预测误差给更高的权重，强制模型重视这部分数据。这一点很多教程里不会提，但对实际效果影响很大。

2.3 特征工程：把时间属性和气象变量变成模型能“吃”的东西

特征工程直接决定深度学习模型的下限。原始数据里只有负荷值和气象数据，要把它变成适合模型训练的输入，需要加工出几类特征：

• 时间类特征：把datetime拆成hour（0-23）、weekday（0-6）、month（1-12）。这几个特征直接输入模型是不行的，因为它们是周期性变量，比如23点和0点其实只差一个小时，但如果用数值直接表示，模型会认为差距很大。常用的做法是one-hot编码，或者用三角函数转成周期特征。我实际用的方案是one-hot，简单有效，对LSTM这种对输入分布敏感的网络更友好。

• 滞后特征：这个是最关键的。负荷预测本质上是用过去预测未来，所以要构造滞后窗口。我用的是过去168小时的负荷数据（即前7天），因为一周的完整周期对负荷的影响非常大。特征矩阵的形式是：每个训练样本是一个形状为(168, 特征维度)的序列，其中第0维是时间步，后面每列分别包括历史负荷、温度、湿度、风速、节假日标记等。

• 差分特征：对负荷序列做一阶差分，可以消除趋势性，让序列更平稳。LSTM对非平稳序列的拟合能力其实不差，但做了差分之后收敛更快，效果也更稳。

• 气象交互特征：温度对负荷的影响是非线性的，比如夏季超过30度之后，每升高一度引起的负荷增量比25度以下要大得多。可以用制冷度日数(CDD)和采暖度日数(HDD)这两个指标来刻画这种效应，公式是：

CDD = max(0, temp - 26)，HDD = max(0, 18 - temp)

这个26度和18度是经验阈值，不同的地区可以根据当地实际用电行为调整。构造出来后，把它作为额外的特征加入输入张量，等于给了模型一个指示“今天热不热”的显式变量。

特征最终拼成了几个维度：负荷数值、温度、湿度、风速、是否节假日、小时、星期、月份。编码方式统一做了归一化处理，尤其是负荷、温度这种数值量级差异大的特征。

2.4 数据集的划分策略

数据划分有个容易被新手忽略的原则：时间序列数据不可以随机切分，必须按时间顺序划分，否则模型会“偷看未来”，训练指标虚高，上线一测就崩。

我的划分方式是：前80%的时间段作为训练集，接下来的10%作为验证集，最后10%作为测试集。验证集用来做模型选择和早停判断，测试集只允许最后用一次，用来评估最终模型的泛化能力。为了公平对比，所有模型的训练集、验证集、测试集划分都完全一致，只有这样才能保证对比结论是有意义的。

具体的时间划分是：2016年1月到2018年12月属于训练集，2019年1月到6月属于验证集，2019年7月和8月（夏季最热时段）作为测试集。用夏季数据当测试集是故意的，因为夏季空调负荷占比高，波动大，是全年预测难度最高的时段。如果这个时段的误差能控制住，其他时候问题都不大。

3. Python源码实现与核心代码解读

3.1 项目结构设计

这个项目的源码我整体用了一个比较清晰的结构，基本是研究型项目标准的目录组织方式。设计这个结构的初衷就是三个字：可复现。不管是自己回头调代码，还是别人拿到你项目想快速上手，一个好的目录结构能省大量时间。

power_load_forecast/ ├── config.yaml # 全局配置文件：路径、超参数、特征配置 ├── data/ │ ├── raw/ # 原始数据存储 │ └── processed/ # 预处理后的数据 ├── src/ │ ├── data_preprocess.py # 数据清洗、特征工程、归一化 │ ├── dataset.py # 构建时间序列滑窗数据集 │ ├── models.py # 模型定义（LSTM、CNN-LSTM、TCN） │ ├── train.py # 训练、验证、早停、模型保存 │ └── predict.py # 加载模型做预测，输出结果 ├── results/ │ ├── figures/ # 训练的图表，比如学习曲线、预测对比图 │ └── predictions/ # 用模型预测的结果csv ├── docs/ │ ├── 项目说明文档.md # 面向读者的整体说明 │ ├── 技术文档.md # 面向开发者的技术细节 │ └── 实验报告.md # 面向导师或评审的工作量证明 └── requirements.txt # Python依赖包列表

config.yaml这个文件看起来简单，实际很管用。所有的超参数都集中在这里，换数据、调参数都不需要去动代码。后面做超参数搜索的时候，只需要在这个文件里改值，然后重新跑训练脚本就行。

3.2 LSTM模型的核心代码

核心模型代码不复杂，我用的PyTorch框架。主模型是一个两层的LSTM，叠加了两个全连接输出层。我把关键代码贴出来，注释也写得比较完整，方便直接参考。

import torch import torch.nn as nn class LSTMNet(nn.Module): def __init__(self, input_size, hidden_size, num_layers, output_size, dropout=0.2): super(LSTMNet, self).__init__() self.hidden_size = hidden_size self.num_layers = num_layers # 核心：多层LSTM # batch_first=True 表示输入的形状为 (batch, seq_len, feature_size) self.lstm = nn.LSTM( input_size=input_size, hidden_size=hidden_size, num_layers=num_layers, batch_first=True, dropout=dropout ) # 输出层：把最后一个时间步的隐状态映射到预测值 # 先接一个全连接层做特征压缩，再输出24个值 self.fc = nn.Sequential( nn.Linear(hidden_size, 64), nn.ReLU(), nn.Dropout(dropout), nn.Linear(64, output_size) # output_size = 24，预测未来24小时 ) def forward(self, x): # x 形状: (batch, seq_len, input_size) lstm_out, (h_n, c_n) = self.lstm(x) # 取最后一个时间步的输出 last_hidden = lstm_out[:, -1, :] # 形状: (batch, hidden_size) output = self.fc(last_hidden) # 形状: (batch, 24) return output

这里有一个设计细节要重点说明：output_size设为24，意味着输入一段过去168小时的序列，模型一次性输出未来24小时的预测值，而不是循环24次、一次预测一小时。一次性输出的好处是训练和推理效率高，而且模型能学到一个完整日曲线的内部约束，预测出来的24个点天然就是一条光滑合理的曲线，不会出现逐点预测那种误差累积的情况。

CNN-LSTM模型的实现思路类似，只是在LSTM之前加了几层一维卷积和池化，把原始序列长度从168压到42左右再做LSTM。TCN模型用的是torch实现，内部是几层膨胀因果卷积。

3.3 训练流程的关键细节

训练循环本身中规中矩，但有几个细节对效果影响很大，必须单独拎出来说。

第一个是早停机制。深度学习模型在训练集上会慢慢达到拟合，但继续训练下去极容易过拟合，验证集的loss会先降后升。我设置了patience=10，也就是连续10个epoch验证集loss都没有下降时，就停止训练，并且保留验证集loss最低的那一版模型。对于这类项目，早停比固定训练轮数好得多，省了很多人工调参的时间。

第二个是学习率调度。我用的是ReduceLROnPlateau策略——训练过程中，如果验证集loss停滞下降连续5个epoch，就把学习率乘0.5。初始学习率是0.001，配合Adam优化器。这种自适应降低学习率的策略，能让训练前期跑得快、后期更精细地收敛。

第三个是损失函数的选择。默认用的是MSE（均方误差）。后来我加了一个小改进：在MSE基础上叠加一个针对峰时段的加权项。具体实现是对每日的8点到11点、18点到21点这两个高峰时段的误差乘以1.5的权重。因为峰时段的负荷水平高，误差的绝对值天然就大，RMSE会被这些点主导。如果模型对峰时段预测不准，MAPE会很难看。加权之后，模型会把更多的“注意力”放在优化峰时段上，整体MAPE指标能有明显改善。

def weighted_mse_loss(pred, target): # 构造权重：高峰时段权重为1.5，其余时段为1.0 weights = torch.ones_like(target) # target 的形状是 (batch, 24)，第8到第10列、第17到第20列对应峰时段 peak_indices = list(range(8, 11)) + list(range(17, 20)) weights[:, peak_indices] = 1.5 return torch.mean(weights * (pred - target) ** 2)

3.4 模型训练和预测的完整跑通方式

数据的加载和训练是最容易出问题的地方，跑的时候要注意几个点。首先是DataLoader的构造，用我之前构建好的滑窗样本集来实现。

from torch.utils.data import Dataset, DataLoader class LoadDataset(Dataset): def __init__(self, X, y): # X: (num_samples, seq_len, input_size) # y: (num_samples, output_size) self.X = torch.tensor(X, dtype=torch.float32) self.y = torch.tensor(y, dtype=torch.float32) def __len__(self): return len(self.X) def __getitem__(self, idx): return self.X[idx], self.y[idx] def create_dataloader(X, y, batch_size=64, shuffle=True): dataset = LoadDataset(X, y) dataloader = DataLoader(dataset, batch_size=batch_size, shuffle=shuffle) return dataloader

训练主循环按标准的PyTorch流程写，需要注意的地方只有一个：epoch循环内要不断调用模型.train()和model.eval()切换模式，因为Dropout和BatchNorm在训练和推理时的行为不一样，这个细节漏了的话，验证效果会被严重干扰。

预测阶段的代码分两种情况：一是直接预测测试集，把输入序列喂给模型就行；二是在业务系统中做滚动预测——用最新的168小时数据预测接下来24小时，等时间往前走一小时，丢掉最旧的数据，加入最新的观测值，再次预测。第二种方式在工程上更常见，模型每次推进一步，实时更新预测结果。

3.5 结果可视化的做法

项目里画了两类图：误差曲线和预测对比图。

误差曲线就是训练集、验证集的loss随epoch的变化曲线，用来判断是否有过拟合迹象，如果验证集loss明显回升，说明模型开始记住了训练集噪声。

预测对比图更直观，把某几天测试集上的真实负荷和预测负荷画在同一个坐标系里。我特意选了一个普通工作日、一个周末、一个高温日来展示。从图上能明显看出三种情况下的预测表现：工作日预测得最准；周末的用电器模式偏向生活化，峰值降低并且后移，模型也能大致跟上；高温日的误差最大，主要是因为空调负荷激增导致曲线形态跟训练集的常态差异太大。这张图放到文档里是最有说服力的实验结论。

多个模型的对比散点图和柱状图也要做，直观展示LSTM、TCN、CNN-LSTM的精度差异，看出哪个模型在哪个时段占优。

4. 配套文档说明的主题安排和写作思路

4.1 文档的作用与读者分析

“源码+文档说明”这个组合，在学术实践类项目里几乎是标配。源码是骨架，文档是血肉。一份好的文档，不只是把代码跑一遍说明，而是要把整个项目“为什么这样做”讲清楚，特别是面向三类读者：导师或评审（验证工作量与专业度）、合作开发者（需要理解设计意图）、未来的自己（三个月后回来看还记得当初的决策）。

4.2 项目说明文档的结构设计

我写的《项目说明文档》包含六个部分，分别对应不同的阅读诉求：

• 1. 项目概述：用一页纸说清楚项目要解决什么问题，用了什么方法，得出什么结论。适合快速浏览的读者。
• 2. 数据说明：数据来源、时间范围、粒度、字段含义、数据质量问题和处理方式。
• 3. 方法与模型：LSTM、CNN-LSTM、TCN的原理简述，为什么选用这些模型，它们各自的适用场景。
• 4. 实验设计：数据集怎么划分、评估指标选什么、超参数怎么配置。特别强调实验的可比性是公平对比的底线。
• 5. 结果分析：预测效果展示、模型对比、典型场景（工作日/周末/高温日）的表现分析。
• 6. 复现指南：环境配置、安装依赖、一键训练、一键预测、结果导出，这样别人拿到项目后不需要来回问你就能自己跑通。我这里写了一个简单的复现步骤，核心就是这个流程：

# 建议使用Python 3.8或以上版本 pip install -r requirements.txt # 数据预处理：把原始csv转成训练可用的特征矩阵 python src/data_preprocess.py # 训练模型：输出结果保存在results/figures/和results/models/ python src/train.py --model lstm # 预测：加载已训练模型并对测试集进行预测 python src/predict.py --model lstm # 一键对比所有模型：跑完后自动输出表格和图表 python src/run_all.py --compare

4.3 技术文档怎么写才有含金量

技术文档我是单独写的一份，重点覆盖的是实现细节。比如滑窗是怎么构造的、特征编码为什么用one-hot、归一化的参数是在哪些数据上拟合的（这一点特别容易翻车，必须只在训练集上fit，然后再transform验证集和测试集，防止信息泄漏）、模型参数初始化方式、不同模型的参数量和训练耗时对比等。

这一部分还包括对几个关键决策的论证，比如归一化为什么用MinMaxScaler而不是StandardScaler。原因是负荷数据的分布有明显的周期性，MinMax能更好地保留原始分布关系。而训练的时候，对标签数据y做的是去归一化之后才计算误差，否则误差数值会被缩放因子扭曲，看不出真实大小。

4.4 用实验报告体现工作量

很多同学的项目文档写得单薄，核心问题是没有完整记录实验过程的波折。我写实验报告的主要套路是：按时间顺序记录实验的推进，每个阶段记录结论并调整下一轮方案。比如我第一次跑LSTM模型，MAPE在3.8%，这个结果已经能看了，但还没有好到可以交差。我记下问题，然后针对性的改进：加入峰时段的加权损失函数之后，MAPE降到2.8%；进一步加CDD特征之后，降到2.3%。这些迭代细节就是研究深度和工作量的最好体现——既证明了模型在改进，也让读者知道整个结果的来龙去脉。

5. 项目里踩过的坑，以及一些想提醒你的经验

5.1 数据泄漏的坑

设计滑窗样本集的时候，如果不够小心就会把归一化参数出错。比如你想用全部的XTrain和XTest数据一起做MinMaxScaler的fit操作，然后让模型在数据“见过未来”的情况下训练，训练出来的指标会极其漂亮，但样本外效果会非常差。这个项目里我最早也犯了这个错误，后来专门写了检查代码：在训练完成之后，单独取出一段训练期内模型“没见过”的连续时段数据来验证，结果发现真实的MAPE比训练时高了一倍多。排查了半天才抓到元凶就是归一化泄漏，改掉之后，效果正常了很多。

5.2 LSTM训练跑不动和显存不足

第一次加载数据时，我没有意识到直接把整个dataframe转成numpy数组再全部转成tensor放进显存有多么离谱。原始数据量虽然不算大，但168个时间步的特征矩阵一旦展开就很占空间。后来用DataLoader的batch机制，每个batch只有64条样本，配合torch的自动释放机制，训练过程内存占用从原来的3.8GB降到400MB。如果你的显存比我的还紧张，还可以考虑降低seq_len（比如从168降到72），代价是模型失去一周周期的参考信息。

5.3 预测值滞后于真实曲线

这是时间序列预测里特别典型的现象：预测曲线比真实曲线“晚一拍”，峰值的出现时间对不上。很多人会误以为模型失效了，实际上这是模型在用前面几小时的趋势惯性硬推后续变化。解决的方案我试验过两种：一是增大seq_len，让模型看到更长的历史参考，它有更多背景信息来校准当前时段的趋势方向；二是把时间特征做得更细，比如加入“当天是几号”这类特征，让模型拿到更明确的时间位置信息。两种方案结合之后，峰值时刻的滞后基本消除，RMSE也相应下降。

5.4 环境配置的兼容性问题

项目里用到的核心依赖是python 3.8 + torch 1.13 + numpy 1.24 + pandas 1.5，环境配置确实不算新潮，但有一个大坑：新版本的Python（比如3.12）对torch 1.13的兼容性不佳，会报错。这种情况我建议直接用conda新建一个py38环境，把所有依赖装在那里，会省很多不必要的折腾。requirements.txt我都固定了版本号，而不是用>=这种“永久浮动版本号”，确保任何人拿到项目都能一键复现我的环境。

6. 自己对项目的一些体会和后续想法

这个项目做完之后，我对“深度学习+”这类研究型项目有了比较实在的感受。模型结构本身不是项目的最大难点，真正耗时的是数据层面和实验设计层面的功夫。数据质量差、特征构造不合理、评估方式不正确，任何一个环节出问题都会让模型的优秀结构完全白搭。做这类项目，一定要把数据处理和实验设计放在和模型结构同等的重视位置。

后续如果想继续深挖，我推荐两个方向：一是对预测结果做区间预测，而不是只输出点预测值。电力系统的实际决策中，一个可靠的误差范围往往比一个单点值更有指导意义——比如用分位损失或者贝叶斯神经网络来实现。二是引入图神经网络，把电网拓扑结构考虑进去，把不同区域的负荷数据建成图结构，让模型自动学习区域之间的相互影响。这种做法在区域级负荷预测中已经有论文验证了效果，也更能体现研究的创新性。

如果你正在做相关的课题，希望这篇内容能让你少走一些我走过的弯路。有具体细节问题，直接按文中的思路跑起来，比干看有效得多。

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