深度学习销量预测实战：京东商品销量预测源码解析与LSTM应用

简介：针对电商平台的销量预测需求，这份工程设计基于深度学习算法，聚焦京东商品销售数据的分析与预测。资源包内共51个文件，压缩后约六点九六兆，包含十份Python源码、十份SQL数据库脚本、十一份CSV数据文件、十二份PNG图像以及配置文件与文本记录等。其中Python代码实现了循环神经网络等模型，提供多个版本供训练对比，支持商品维度和用户维度的销量预测；SQL脚本完成业务数据建表和特征信号生成；CSV数据保存训练样本与最终提交结果；PNG图像展示各模型在训练集和测试集上的ROC曲线，便于比较效果。读者可从中掌握时间序列预测的数据清洗、特征工程、模型构建与评估调优方法，也可将整套工程作为销量预测比赛的基线方案，快速迭代改进。目前已有三百四十二人学习下载，适合电商数据分析师、算法工程师及深度学习方向的学生参考。

1. 为什么说京东商品销量预测是最适合练手的深度学习实战项目

「基于深度学习的京东商品销量预测设计源码」这套标题，你搜到的不是一篇论文，而是一整套能落地的工程交付物：从一张包含订单明细的表格，到屏幕上画出未来 7 天销量曲线，中间隔着数据清洗、特征工程、时序模型、可视化界面四层，每一层都有真实业务里才能遇到的坑。很多同学拿到打包好的源码，以为解压即用，结果卡在环境装不上或预测结果是一条水平直线这两道坎上。我按实际做这类销量预测项目的顺序往下拆，从源码结构说起，把特征怎么构造、模型怎么选、参数怎么调、数据泄漏怎么防一次讲清楚。这篇文章适合正在做课程设计或毕业设计的学生，也适合想拿销量预测入门深度学习的从业者照着复现。

2. 一套销量预测源码的三层骨架：先看文件结构，再谈模型选型

2.1 课程设计源码的固定骨架：数据、特征、模型、界面

拿到任何一份「XX预测设计源码」，第一件事不是打开模型文件，而是先把目录结构过一遍。常见做法是项目包分成四块：data 管数据进出，features 管特征工程，models 管网络定义和训练，web 或 ui 管结果展示。下面这个目录结构是这类源码最常见的组织方式，具体命名可能不同，但功能划分八九不离十：

sales_forecast/ ├── data/ # 原始数据与清洗后数据 │ ├── raw_orders.csv # 原始订单流水 │ └── processed/ # 清洗聚合后的日粒度数据 ├── features/ │ └── build_features.py # 特征工程脚本 ├── models/ │ ├── lstm.py # 模型结构定义 │ ├── trainer.py # 训练入口 │ └── predict.py # 加载模型做预测 ├── web/ │ ├── app.py # Flask 展示端 │ └── templates/ └── config.py # 全局参数配置

先看 data 目录，确认原始数据是订单流水还是已经聚合好的日销量表，这决定了特征工程要从哪一步做起。再看 models 目录里有没有保存好的权重文件，很多源码包只给训练脚本不给训练好的模型，这意味着你拿到手必须自己跑一遍。最后看 config.py，训练轮数、学习率、序列长度这些参数通常都集中在这里。

这套源码的逻辑链条很清晰：订单流水经过聚合变成日粒度序列，特征工程把促销、价格、周期这些信号加进去，模型读入滑动窗口切片，输出未来若干天的销量预测，最后通过 Flask 页面或图表展示。任何一个环节断了，整个源码就跑不通。所以排查问题也按这个链条一层层来，先查数据，再查特征，最后才查模型。

2.2 LSTM、CNN 与 Transformer 怎么选：序列长度和数据量说了算

很多初学者拿到销量预测源码，第一反应是「模型越新越深越好」，于是上来就上 Transformer，结果几千条数据训出来的效果还不如线性回归。课程设计场景下选模型，先看两个硬指标：序列长度和数据量。下面这张表是我做选型时的经验判断。

以课程设计的数据体量来说，LSTM 或 GRU 是最稳的默认选择。原因很实在：第一，销量预测本质是回归问题，不需要 Transformer 那么强的长程依赖建模能力；第二，LSTM 的时序逻辑直观，论文里画个细胞结构图就能把原理讲明白，Transformer 的自注意力机制解释起来费劲；第三，LSTM 对训练数据量的要求低，几千条窗口样本就能收敛出像样的结果。

如果源码里用的是 TensorFlow 的 Keras 接口，模型主结构通常会是这样：

# models/lstm.py from tensorflow import keras from tensorflow.keras import layers def build_lstm_model(seq_len=30, horizon=7, n_features=8): """构建销量预测用的 LSTM 模型。 参数： seq_len: 输入窗口长度，看过去多少天 horizon: 预测未来多少天 n_features: 每个时间步的特征数量 """ model = keras.Sequential([ layers.Input((seq_len, n_features)), layers.LSTM(64, return_sequences=True), layers.LSTM(32), layers.Dense(horizon) # 直接输出未来 horizon 天的销量 ]) model.compile( optimizer=keras.optimizers.Adam(1e-3), loss="mse", metrics=[keras.metrics.RootMeanSquaredError(name="rmse")] ) return model

这段代码里两个 LSTM 层堆叠是常见做法：第一层 return_sequences=True 保留每个时间步的中间输出，让第二层继续提取更高层的时序模式；最后一层 Dense 的神经元个数等于预测天数，输出一个向量而不是一个标量，这样一次预测就能给出未来 7 天的销量曲线。损失函数用 MSE 是因为销量预测的误差要按平方惩罚大偏差，RMSE 作为监督指标更接近实际业务感受。

如果你拿到的源码用的不是这种结构，而是把输出层设计成每天一个模型或做了分类分桶，也别急着改，先看它的预测任务定义。有的源码把销量预测做成「涨跌分类」而不是「数值回归」，评估方式完全不同，跑通之前别混用。

3. 把订单流水变成模型认识的数字：京东场景的特征工程要怎么做

3.1 订单流水先变成日粒度序列：这一步决定后面所有特征的质量

模型不认识订单流水，只认识等间距的时间序列。京东这类电商平台的订单表通常长这样：每一行是一条成交记录，包含支付时间、商品 ID、购买数量、成交价格、促销信息等字段。第一步永远是把流水聚合到「商品 + 日期」粒度：

import pandas as pd # 原始订单流水：一行一条成交记录 raw = pd.read_csv("data/raw_orders.csv", parse_dates=["pay_time"]) # 提取日期列 raw["date"] = raw["pay_time"].dt.date # 按商品和日期聚合，得到每天每个商品的销量 daily = raw.groupby(["sku_id", "date"])["qty"].sum().reset_index() daily = daily.sort_values(["sku_id", "date"]).reset_index(drop=True) # 把缺失日期补全为 0 all_dates = pd.date_range(daily["date"].min(), daily["date"].max(), freq="D") daily = ( daily.set_index("date") .groupby("sku_id")["qty"] .resample("D") .asfreq(0) .reset_index() )

这段代码的核心是 resample("D")，把订单流水按天对齐。为什么要补全日期为 0？因为神经网络默认时间步是连续等距的，某天没有成交记录如果直接缺失，序列就会多出空洞，LSTM 学到的是错位的规律。补 0 虽然粗暴，却是时序任务里最可复现的做法。

这里注意一个细节：补 0 会引入一个业务问题，缺货期和真的零销量在数字上都是 0，但成因完全不同，缺货期的 0 不代表「没人买」。这个问题在第五章单独展开，特征层面先按 0 处理，后面用掩码特征区分。

3.2 三个京东场景的高频特征：促销标记、价格变动、品类生命周期

日销量序列是模型的骨架，但京东商品的销量波动受三个外部信号驱动：促销活动、价格调整、商品所处生命周期阶段。这三个信号不变成特征，模型就只能靠「猜」来应对双 11 这类脉冲。

# features/build_features.py def build_shop_features(df): """构造京东场景销量预测的关键特征，df 为日粒度数据。""" # 按商品排序，保证 shift 是按时间先后取数 df = df.sort_values(["sku_id", "date"]) # 1. 历史销量滞后特征：看 7 天前和 14 天前卖了多少 df["sales_lag_7"] = df.groupby("sku_id")["qty"].shift(7) df["sales_lag_14"] = df.groupby("sku_id")["qty"].shift(14) # 2. 近 7 天滚动均值：平滑短期波动 df["sales_ma_7"] = ( df.groupby("sku_id")["qty"] .rolling(7) .mean() .reset_index(level=0, drop=True) ) # 3. 是否处于促销期：按活动字段生成 0/1 掩码 df["is_promotion"] = (df["promo_flag"] > 0).astype(int) # 4. 价格变动：相对前一天的价格差 df["price_diff"] = df.groupby("sku_id")["price"].diff() # 5. 商品上架天数：刻画新品爬坡期还是成熟稳定期 df["sku_age_days"] = ( df.groupby("sku_id")["date"].transform(lambda x: (x - x.min()).dt.days) ) return df

逐个解释这五个特征的用途。sales_lag_7 和 sales_lag_14 让模型知道「上周今天卖了多少」，销量预测里周周期性非常强，周末和工作日的差距远大于相邻两天，lag 特征是最直接的周期编码。sales_ma_7 是移动平均，相当于给模型一个去噪后的基准线。is_promotion 是促销掩码，直接用 0/1 告诉模型「今天在搞活动」，比让模型自己从销量数字里猜活动要可靠得多。price_diff 捕捉降价刺激：京东的秒杀、百亿补贴通常伴随价格跳水，价格差为负且幅度大时，销量往往会拉出一根尖峰。sku_age_days 是商品上架天数，新品有爬坡期，老品可能进入衰退期，同一个销量数字放在不同生命周期阶段含义完全不同。

3.3 滑动窗口与训练集切分：时序数据里最容易翻车的一步

特征构造好之后，要切成模型能吃的窗口样本。滑动窗口的思想是：用过去 seq_len 天的数据，预测未来 horizon 天。这一步看起来简单，但切分方式直接决定模型能不能用。

import numpy as np def make_windows(df, seq_len=30, horizon=7): """把日粒度序列切成 [输入窗口, 预测目标] 的样本对。""" X, y = [], [] for sku_id, d in df.groupby("sku_id"): values = d["qty"].values # 滑窗：i 是窗口起点，i+seq_len 是预测起点 for i in range(len(values) - seq_len - horizon + 1): X.append(values[i:i + seq_len]) y.append(values[i + seq_len:i + seq_len + horizon]) return np.array(X), np.array(y) # 按时间顺序切分训练集与验证集，绝不随机打乱 split_date = pd.Timestamp("2024-10-31") train_df = df[df["date"] <= split_date] val_df = df[(df["date"] > split_date) & (df["date"] <= "2024-12-31")] X_train, y_train = make_windows(train_df) X_val, y_val = make_windows(val_df)

关键点在于最后一行的切分方式：训练集是 10 月 31 日之前的全部窗口，验证集是之后一个月。这里绝对不能用 sklearn 的 train_test_split 随机切分，因为销量序列有强时间连续性，相邻日期的样本高度相似，随机切分会把「看到未来数据」泄漏给验证集，表面指标很好看，实际业务上一预测就露馅。

窗口长度选择上，课程设计场景我一般用 seq_len=30，horizon=7，原因是 30 天刚好覆盖一个月度销售周期，7 天覆盖一周，能抓到周周期性。如果你的数据里有明显的月度促销节奏，可以加大到 45 或 60，但窗口越长，样本数量越少，数据量小的数据集撑不住。特征处理完别忘做归一化，LSTM 对输入尺度敏感，用 sklearn 的 StandardScaler 按特征列标准化即可，但归一化参数只能从训练集上拟合，验证集和测试集直接用同一套参数转换，这个细节直接关系到第五章说的数据泄漏问题。

4. 从环境到界面：把销量预测源码跑通的最小路径

4.1 深度学习环境配置：先定 Python 版本再装依赖

第一步永远是环境，这是深度学习实战项目案例里劝退率最高的一环。很多源码跑不起来不是因为代码问题，而是 TensorFlow、PyTorch、Python 版本互相打架。我的建议是先创建独立虚拟环境，再按顺序装依赖，不要直接往系统 Python 里灌。

# 创建 Python 3.10 独立环境 conda create -n sales python=3.10 -y conda activate sales # 先装基础数据处理库，再装深度学习框架 pip install pandas numpy scikit-learn matplotlib flask pip install tensorflow # CPU 版先跑通再说

注意最后一行，课程设计的销量数据量通常在几千到几万条，CPU 版 TensorFlow 完全能跑，训练一轮也就几十秒。先装 CPU 版把代码跑通，确认预测结果合理，再考虑要不要换 GPU 版。不少人一上来就折腾 CUDA、cuDNN，装了两天环境还没开始跑模型，这是典型的投入产出比失衡。

如果你的源码是基于 PyTorch 写的，命令类似，把 tensorflow 换成 torch 就行。逻辑是一致的：先保证最简环境能运行，再谈加速。

4.2 训练脚本里最值得调的四个参数：epoch、batch_size、学习率、早停

跑通源码后第一件事是看 config.py 里的参数，很多源码把参数写死在训练脚本里，你要做的是理解它们而不是照抄。我整理了一张参数表，覆盖训练阶段最影响结果的四个开关。

对应到训练脚本里，Keras 的写法是这样的：

# models/trainer.py EPOCHS = 80 BATCH_SIZE = 64 LEARNING_RATE = 1e-3 PATIENCE = 12 model.compile( optimizer=keras.optimizers.Adam(LEARNING_RATE), loss="mse", metrics=[keras.metrics.RootMeanSquaredError(name="rmse")] ) # 早停：验证集 loss 连续 12 轮不下降就停止，并回滚到最佳权重 early_stop = keras.callbacks.EarlyStopping( monitor="val_loss", patience=PATIENCE, restore_best_weights=True ) history = model.fit( X_train, y_train, epochs=EPOCHS, batch_size=BATCH_SIZE, validation_data=(X_val, y_val), callbacks=[early_stop], verbose=1 )

早停是这里面性价比最高的一个参数。它做的事情很简单：每轮训练完看一次验证集 loss，如果连续 12 轮都没有比历史最好更低，就主动停掉，并且把模型权重回滚到最好的那一轮。没有早停的模型很容易在 50 轮之后开始死记训练集，训练 loss 还在降，验证 loss 已经反弹，这就是过拟合。restore_best_weights=True 这个参数很多人忘写，不写的话早停只负责停，不停在最好的权重上，白训了。

学习率方面，Adam 加 1e-3 是通用起点。如果训练 loss 一直在震荡不下降，优先降学习率到 1e-4，不要上来就改网络结构。调参是玄学，但学习率不是，它是最有确定性的旋钮。

4.3 可视化输出：预测结果怎么展示才让答辩老师一眼看懂

模型训完之后，输出不能只是一行数字，要画图。销量预测类项目最核心的交付物是「未来 7 天销量预测曲线」，用 matplotlib 画真实值与预测值的对比是最直观的呈现：

import matplotlib.pyplot as plt # 取某个商品的预测结果，pred 是模型输出，y_test 是真实值 plt.figure(figsize=(12, 5)) plt.plot(y_test[0], label="真实销量", marker="o") plt.plot(pred[0], label="预测销量", marker="s") plt.xlabel("未来天数") plt.ylabel("销量") plt.title("某商品未来 7 天销量预测") plt.legend() plt.grid(alpha=0.3) plt.savefig("docs/predict_curve.png", dpi=150)

画预测曲线有两条经验：第一，必须和真实值画在同一张图上，单独画一条预测曲线没有参考系，看不出准不准；第二，横轴用「未来第 1 天、第 2 天……」，不要用具体日期，这样展示时更方便讲模型输出结构。

如果源码自带 Flask 网页，通常就是读入训练好的模型，前端表单选一个商品 ID，后端现场算预测结果并回传页面。这类展示端课程设计里很加分，但要注意模型的加载路径，用相对路径从项目根目录找模型文件，避免换电脑后路径失效。Python 里模型加载失败最常见的报错就是路径写死成绝对路径，换台电脑就崩。

5. 京东销量预测源码避坑实录：数据泄漏、零销量与玄学调参

5.1 验证集 R² 高得离谱，预测曲线却滞后一天：你让模型看到了未来

这是做时间序列预测最隐蔽的坑，也是我见过翻车最多的现象。表现是训练时验证集 R² 高达 0.95，看起来完美，但把预测结果逐日画出来，发现曲线比真实值整体滞后一天，或者第一天的预测几乎等于前一天的真实值。

根因百分之九十是数据泄漏。常见泄漏途径有两处：一是滑动窗口切分时没有按时间顺序，随机切分让模型在训练时见过验证集相邻日期的数据；二是归一化时用整段数据的均值和方差去 scaling，相当于把未来数据的分布信息泄漏给了过去。还有一个更隐晦的：滞后特征 shift 的时候没有先按商品分组再 shift，导致上一个商品的最后一天泄漏给下一个商品的第一天。

解决方法是把数据准备流程固定成三步：先按商品分组，在组内做 shift 和滚动特征；再按时间顺序切出训练、验证、测试三段；最后只从训练段拟合 StandardScaler 的均值和方差，验证测试段用同一套参数 transform。这三步顺序不能乱，乱一步模型就废了。

5.2 缺货商品全零序列把模型学成一潭死水

京东商品经常断货，断货期间日销量是 0，补货后销量又恢复。如果把这个全零段直接喂给模型，LSTM 很容易学出一个「永远预测低销量」的保守输出，因为全零段在训练数据里占比不小，模型优化时发现预测成 0 的误差也说得过去。

更深层的问题是 0 的含义被混淆了。缺货期的 0 是「没货可卖」，不是「没人买」，模型分不清这两者，就会把缺货信号当成需求信号。

处理方式有两种，我一般组合使用：第一，在特征里加一个「是否缺货」的 0/1 掩码列，让模型知道这段零销量的成因；第二，训练集里把连续缺货超过 7 天的时段剔除，因为这种长零序列对学习销售规律没有贡献。另外可以对销量做 log1p 变换压缩长尾，让模型不用在 0 到几千的跨度里硬学，收敛会快很多。

5.3 大促日的预测直接腰斩：促销脉冲没有进特征

双 11 当天销量是平日的十几倍，模型预测结果却只有实际的一半甚至三分之一。这不是模型学不会，而是你根本没告诉它今天在促销。

有些源码只用了历史销量做特征，模型不知道促销活动存在，看到前一天销量还在几百、第二天突然冲到一万，只能当成异常波动平滑掉。神经网络不擅长凭空推断它没见过的模式。

解决方法是把活动信息显式编码成特征。我在 3.2 节里写了 is_promotion，这是最基础的版本。更进一步的做法是构造「距大促还有几天」的序列特征，比如双 11 前 7 天开始倒数，这个倒计时特征能帮模型学出「大促前用户憋单、大促当天集中释放」的行为模式。真实业务里这种节前抑制、节中爆发的形态非常明显，特征给到位，模型才学得出来。

5.4 loss 震荡不降或指标一动不动：学习率与数据顺序的锅

训练时 loss 曲线要么剧烈震荡就是整体不下降，先把网络结构放到一边，排查两个东西。

第一个是学习率。Adam 的 1e-3 是起点不是真理，不同数据分布下模型对学习率的容忍度差别很大。loss 上下乱跳就降到 1e-4，loss 平坦得像一条直线就升到 3e-3，一次改一个数量级，别两个参数同时动，否则你永远不知道是谁起作用。训练轮数也要确认，我见过有人只跑了 3 轮就说模型不收敛，LSTM 至少要 20 轮才进入稳定下降区间。

第二个是训练数据的样本顺序。滑动窗口切出来的样本，如果按时间顺序依次进 batch，相邻样本高度相似，梯度更新方向会很偏，模型一圈圈原地打转。解决方式是在训练阶段把样本索引打乱，也就是 Keras 默认的 shuffle=True。注意这个 shuffle 只在样本层面做，训练、验证、测试三个集合的边界绝不能越过。

5.5 换台电脑模型就崩：版本、路径与模型保存方式的连环坑

在 A 机器上训练好的模型，拷到 B 机器上加载直接报错，这是源码换环境最常见的翻车现场。报错五花八门，有的说 Unknown layer，有的说无法解析权重文件，有的说路径找不到。

分三类原因处理。第一类是版本不一致：训练时用的 TensorFlow 2.10，加载时换成 2.15，部分算子的序列化格式变了。解决方法是把所有依赖写进 requirements.txt 并锁版本，新环境一条命令还原。第二类是自定义层丢失：源码里如果写了自定义 Attention 层或自定义 Loss，加载模型时必须把自定义对象传进去，Keras 的 load_model 默认不认自定义层，报错信息又很抽象。第三类是路径问题：模型文件加载用的是绝对路径，我一般改成从 config.py 读取相对路径，配合 os.path.join 拼接，保证项目目录挪到哪里都能找到权重文件。

保存模型也要统一方式。课程设计里常见两种：Keras 的 model.save() 保存 .h5 或 .keras 文件，这是首选；另一种是只保存权重 model.save_weights()，这种方式加载时必须先重建一模一样的网络结构，代码一改权重就废，相当麻烦。没有后悔药，统一用 model.save() 最省心。

6. 从「跑通源码」到「说得清模型」：两个能写进论文的验证习惯

6.1 全盲冷启动检验：换一批模型没见过的商品去预测

训练和评估都用同一批商品，模型泛化能力到底如何，其实是被高估的。我现在的习惯是，在训练阶段从数据里挑出 5 到 10 个商品完全不参与训练，等模型训完，用它们的最近 30 天销量序列去预测未来 7 天。这样做的道理很简单：预测一个模型见过的商品，它可能只是在回忆；预测一个完全没见过的商品，才真正检验它有没有学到销售规律。京东平台每周都上新品，冷启动是真实业务里绕不开的场景，论文里写一笔「模型对新品的预测能力」，含金量比反复调高验证集 R² 高得多。

6.2 把误差按星期、促销、节前分组：指标好看不如切片可信

整体 MAPE 只有 15%，答辩老师一句「哪些天不准」就能问住你。避免这个尴尬的办法是把模型的预测误差拆开看：把测试集的结果按周一至周日分组，按是否促销日分组，按节假日前 3 天分组，分别计算误差。做一次数据透视表你就知道，模型的问题往往集中在少数几个切片里——你可能发现周末误差翻倍，或者促销日误差大得离谱。把这些切片误差写进文档，比只写一个总指标可信得多，面试官和老师都吃这一套。

我做这类项目最大的教训是：早期迷信更深的网络，结果数据泄漏占掉了八成问题，模型结构反而没那么关键。现在每版模型出来，固定先跑冷启动和分片误差，再谈调参，每次都能省下一整周的返工时间。这套验证习惯希望帮到你。

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