企业官网建设流程全解析

简介：一套基于Java Spring Boot + Vue + MySQL的物流管理系统完整毕业设计项目，面向计算机相关专业学生，主要解决毕设选题、前后端整合开发、数据库设计与项目部署等实际需求。项目内含前端Vue页面与组件、后端Java业务逻辑、数据库建表脚本，并配套毕业设计论文、功能文档和演示材料，下载后无需额外改造即可运行，适合直接参考或进行二次开发。资源包共402个文件，以java源码、vue组件、svg图标、jpg/png图片、js脚本和xml配置为主，同时包含sql数据库脚本、doc文档及辅助工具脚本，压缩包整体约21.59MB，目录结构清晰，便于按模块检索与学习。系统覆盖订单管理、库存管理、运输配送、报表统计等物流业务核心模块，前端界面友好、操作路径明确，后端逻辑分层清晰，能够完整体现从数据库设计到前后端联调的项目流程。目前已有58人浏览学习，是一份经过严格调试、确保可运行的完整毕业设计资源，对课程设计与期末大作业同样具有较高参考价值。

1. 物流管理系统这个压缩包：一次全栈毕业设计的完整闭环

晚上十点，手机屏幕亮起，学弟发来一条微信：“Spring Boot 起不来，日志一整页红字。”他手里拿的正是这个典型的毕业设计压缩包：基于 java + springboot + vue + mysql 的物流管理系统，附带源码、数据库脚本和论文。我让他别急着改代码，先把三件事按顺序做掉——建库、起后端、起前端，半小时后登录页就出来了。这类物流管理系统的本质，是让一个人独立跑通“前端页面 → 后端接口 → 数据库表”的最短全栈链路。它解决的不是物流业务有多复杂，而是 Spring Boot 和 Vue 怎么在同一个项目里协同工作、数据库怎么支撑订单与车辆流转。适合第一次接触前后端分离项目的学生，也适合想快速搭一套管理系统模板的开发者。这篇文把我跑这类系统时最常用的一套步骤和踩进去过的坑写清楚，你照着做就能把项目跑起来。

2. 拆开Zip先别急着双击：用这5个文件判断Spring Boot工程能不能跑

拿到“源码+数据库+论文”的压缩包，第一步不是解压后立刻用 IDEA 打开，而是先建一个干净目录解压，确认交付物里有哪几块。这类毕业设计项目的标配是三块：Spring Boot 后端源码、Vue 前端源码、SQL 数据库脚本，外加一份论文文档。但真正决定项目能不能跑起来的，是五个关键文件——pom.xml、application.yml、package.json、vue.config.js 和 sql 脚本。它们分别对应后端依赖、后端配置、前端依赖、前端代理和数据库结构。先花五分钟把这五个文件找齐，比盲目启动省两个小时。

2.1 一张图拆出三个模块

解压后我看到的大多是这样一种目录布局，和你的包不一定一字不差，但思路一致：

物流管理系统/ ├── 源码/ │ ├── backend/ # Spring Boot 后端工程 │ │ ├── pom.xml │ │ ├── src/main/java/ │ │ └── src/main/resources/ │ │ └── application.yml │ ├── frontend/ # Vue 前端工程 │ │ ├── package.json │ │ ├── vue.config.js │ │ └── src/ │ │ ├── router/ │ │ ├── views/ │ │ └── api/ │ ├── sql/ │ │ └── logistics.sql └── 论文文档/ └── 毕业论文.docx

别急着对照目录名，先找那五个文件。pom.xml 决定后端是什么 Spring Boot 版本、用了哪些依赖；application.yml 决定端口、数据库连接和 MyBatis 配置；package.json 决定前端 Vue 版本和组件库；vue.config.js 决定前端端口和跨域代理怎么走；sql 脚本决定建库建表的数据基础。五样东西齐了，项目骨架才完整。如果发现 sql 目录下是空的，后面所有数据初始化都得从零写，工作量大很多。

还有一个细节容易被忽略：解压时留意有没有 CRC 校验失败之类的提示。我遇到过压缩包在传输过程中损坏，解压出来少几个文件，启动时怎么都报类找不到。先确认压缩包本身是完整的，再进入下一步。

2.2 版本选型：JDK、Maven、Node、MySQL为什么必须提前定死

这类系统最常见的版本组合是 Spring Boot 2.x + Vue 2.x + MySQL 5.7/8.0。但拿到手不能靠猜，直接看 pom.xml 里的 parent 节点：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent>

这段定义了一个 Spring Boot 2.7.18 的子工程。2.x 系列用 JDK 8 或 JDK 11 都能跑，但如果你本机装的是 JDK 17，启动时大概率会报UnsupportedClassVersionError，原因不是代码写错，而是 class 文件版本和 JVM 版本不匹配。反过来，如果 pom.xml 里是 3.x 版本，JDK 就必须上 17。我在陪人跑项目时最常说的一句话是：先看版本，再调环境，版本不对直接翻车。

前端的版本判断看 package.json 的 dependencies 字段：

"dependencies": { "vue": "^2.6.14", "element-ui": "^2.15.13", "axios": "^1.2.0", "vue-router": "^3.5.1" }

看到 vue 2.6 + element-ui，这是典型的 Vue 2 技术栈，配套的 Node 版本最好在 14 到 16 之间。Node 18 以上不是完全不能用，但在安装 node-sass 时经常因版本不匹配报错。如果看到 vue 3 + element-plus，那就要换一套安装逻辑。版本匹配没有玄学，全是看得见的规则，整理成表就是这样：

2.3 用IDEA和Maven把Spring Boot后端先跑起来

我习惯先跑后端，因为后端是数据来源，前端页面再漂亮，接口不通也是白搭。用 IDEA 打开 backend 目录后，先确认右下角显示的 JDK 版本和 pom.xml 要求一致，再打开 Maven 面板，先执行 clean，再执行 package。命令行操作也可以：

# 在 backend 目录下执行 mvn clean package -DskipTests java -jar target/*.jar

-DskipTests的意思是跳过测试用例编译执行，毕业设计项目里测试类通常可有可无，跳过能省时间。target/*.jar是 Maven 构建出来的可执行 jar 包，java -jar启动它。如果编译过程在下载依赖时卡死，最常见的原因是 Maven 中央仓库访问慢，这时候配置阿里云镜像比傻等有效：

<mirror> <id>aliyun</id> <mirrorOf>central</mirrorOf> <url>https://maven.aliyun.com/repository/public</url> </mirror>

这段要加到 Maven 的 settings.xml 里的<mirrors>节点，全局生效。镜像只解决下载慢，不解决代码编译错误，所以日志里看到大量红字时要分清是网络失败还是代码问题。

后端启动成功的标志是控制台最后出现类似这样的日志：

Tomcat started on port(s): 8080 (http) with context path ''

这行日志说明 Spring Boot 内嵌的 Tomcat 起来了，HTTP 服务监听在 8080 端口。但要注意，后端启动成功不代表数据库连接没问题，真正的数据库错误往往在你第一次调用接口时才出现。所以下一步必须把数据库准备好，后端才能跑通完整链路。

3. MySQL数据库角色：5张核心表与初始化脚本的一条龙跑法

物流管理系统里最容易被低估的是数据库。Spring Boot 和 Vue 是门面，真正撑起业务的是表结构设计。在这类项目里，订单、车辆、用户、仓库几个实体怎么串，直接决定后端接口怎么写、前端页面怎么跳。

3.1 物流业务的数据骨架：订单、用户、车辆、仓库怎么串

打开 sql 脚本扫一遍建表语句，核心表基本离不开这几个。sys_user 管登录和权限；logistics_order 是物流订单主表，记录货物从哪到哪、当前状态；vehicle 管车辆信息；driver 关联司机；warehouse 是仓库节点。订单表是全局的中心，其他表都向它靠拢。

CREATE TABLE logistics_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', order_no VARCHAR(32) NOT NULL UNIQUE COMMENT '运单编号', sender_name VARCHAR(50) COMMENT '发货人', receiver_name VARCHAR(50) COMMENT '收货人', cargo_name VARCHAR(100) COMMENT '货物名称', cargo_weight DECIMAL(10,2) COMMENT '货物重量(kg)', origin_city VARCHAR(50) COMMENT '始发城市', dest_city VARCHAR(50) COMMENT '目的城市', warehouse_id BIGINT COMMENT '关联仓库ID', vehicle_id BIGINT COMMENT '关联车辆ID', status TINYINT DEFAULT 0 COMMENT '0待分配 1运输中 2已签收 3异常', create_time DATETIME COMMENT '创建时间', update_time DATETIME COMMENT '更新时间', CONSTRAINT fk_order_warehouse FOREIGN KEY (warehouse_id) REFERENCES warehouse(id), CONSTRAINT fk_order_vehicle FOREIGN KEY (vehicle_id) REFERENCES vehicle(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='物流订单表';

这段 DDL 的核心在 status 字段。整个系统的状态机围绕它转：管理员创建订单后状态是 0，分配车辆后变 1，司机确认送达后变 2，异常情况置 3。前端下拉框的选项、后端接口里的 if-else、论文里的业务流程图，全部围绕这个字段展开。你拿到手的表名可能不叫 logistics_order，可能是 t_order 或 tb_logistics_order，但字段设计基本逃不开这个骨架。

还要注意脚本里有没有初始数据。很多项目会预置一个管理员账号，如果没有这条 INSERT，你费半天劲启动前后端，登录页永远提示账号不存在。经典初始数据是这样：

INSERT INTO sys_user (username, password, real_name, role) VALUES ('admin', 'e10adc3949ba59abbe56e057f20f883e', '系统管理员', 'ADMIN');

这串看起来像乱码的字符串是 MD5 加密后的 123456，很多毕业设计默认初始密码就是它。但也别拿到手就假设一定是 MD5——如果密文开头是$2a$，那用的是 BCrypt。判断方式很简单，打开后端源码里处理密码的工具类或注册接口，看它用什么算法，再回来看初始数据。

3.2 执行初始化SQL：字符集与权限一次弄好

数据库初始化最常见的翻车点不是 SQL 语法错，而是字符集不对。Linux 环境下 MySQL 默认 character_set_server 有些是老编码，导入后中文全变问号。所以我建库时会显式指定字符集：

mysql -uroot -p -e "CREATE DATABASE logistics DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;" mysql -uroot -p logistics < sql/logistics.sql

第一条命令创建名为 logistics 的数据库，utf8mb4 是支持中文和特殊符号最稳妥的字符集。第二条命令通过 shell 重定向把 sql 文件内容喂给 mysql 客户端，导入到 logistics 库。如果你是 Windows 环境下直接在 mysql 命令行里操作，可以把第二条换成：

USE logistics; SOURCE C:/path/to/sql/logistics.sql;

SOURCE 是 mysql 客户端内置命令，效果和重定向一样，路径里别用反斜杠，用正斜杠或双反斜杠。

导入完成先验证一下，别急着启动后端：

SHOW TABLES; SELECT COUNT(*) FROM sys_user;

SHOW TABLES 列出所有表，如果只有两三张表，说明导入过程可能被中断，或者 sql 脚本本身不完整。COUNT 查用户表，能查到初始数据才算真正成功。

权限方面，我不建议项目连 root 账号。给系统单独建一个账号，数据库层面做最小权限控制，这也是论文答辩时能拿得出手的安全设计：

CREATE USER 'logistics'@'localhost' IDENTIFIED BY 'Logistics@2024'; GRANT ALL PRIVILEGES ON logistics.* TO 'logistics'@'localhost'; FLUSH PRIVILEGES;

localhost 限制只能本机连接，如果之后要把系统部署到服务器上，需要把 localhost 改成'%'或用云数据库的内网地址。这个账号后续要填进 Spring Boot 配置，密码别用太简单的，也不要和 root 密码一致。

3.3 连接参数逐行解释与常见连接错误

数据库建好，接下来让 Spring Boot 认账。打开 backend 的 application.yml，单数据源配置一般是这样的：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/logistics?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: logistics password: Logistics@2024 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: map-underscore-to-camel-case: true

这段配置值得逐行看懂。URL 里localhost:3306/logistics是数据库地址和库名；useUnicode=true&characterEncoding=utf8是中文不乱码的关键，缺了它，即使表是 utf8mb4，连接层也可能把字符集搞乱。serverTimezone=Asia/Shanghai是 MySQL 8 驱动强制要求带的参数，不带会报时区错误。allowPublicKeyRetrieval=true解决 MySQL 8 的 caching_sha2_password 认证插件在连接握手时的一个兼容问题，不带可能连接失败。driver-class-name 用的是com.mysql.cj.jdbc.Driver，对应 MySQL 8 驱动；如果是 5.7，用com.mysql.jdbc.Driver。

MyBatis 的 mapper-locations 配置也很关键，classpath*:mapper/**/*.xml告诉框架去 classpath 下所有 mapper 目录里找 XML 映射文件。路径不对，后端的 Service 调用 Mapper 接口时就会报Invalid bound statement，这个在第 5 章专门展开。

配置改完重启后端，如果还报错，多数是两类：Communications link failure表示数据库没起来、3306 端口被占或防火墙挡了；Access denied for user表示账号密码和 MySQL 里对不上。这两类错误占了数据库连接问题的大半。

4. 前端Vue与后端Spring Boot联调：从npm install到页面出数

后端把数据接口暴露出来，前端要做的就是把接口在页面上渲染出来。这套系统的前端基本是 Vue 2 技术栈：Element UI 做界面组件，Vue Router 做页面跳转，Axios 发请求拿数据。整个联调过程可以拆成三个环节：确认依赖、配好代理、打通登录。

4.1 识别Vue前端的技术栈：vue cli、router、axios

打开 frontend 目录，先看 package.json 确认是 Vue 2 还是 Vue 3，再看 src 下有没有 api 目录和 router 目录。一个典型的 Vue 2 项目结构长这样：

frontend/ ├── package.json ├── vue.config.js └── src/ ├── main.js ├── api/ │ └── request.js ├── router/ │ └── index.js ├── views/ │ ├── login.vue │ ├── dashboard.vue │ └── order/ │ └── index.vue └── components/

api 目录里通常有一个封装好的 Axios 实例，这是前端所有请求的入口。你应该先看它，因为它决定了代理怎么写、token 怎么传：

// src/api/request.js import axios from 'axios' const request = axios.create({ baseURL: '/api', // 代理模式下不需要写死后端地址 timeout: 10000 }) // 请求拦截器：把登录后拿到的 token 带上 request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }) export default request

baseURL 为什么写/api而不是http://localhost:8080？这是为了配合 vue.config.js 的代理配置，让浏览器始终请求同源地址，从根上规避跨域。token 放在 Authorization 头里是 JWT 认证的常見写法；如果这个项目用的不是 JWT 而是 Session，token 机制就要重新确认，别机械照搬。

4.2 devServer代理、跨域与登录态传递

Vue 的开发服务器默认跑在 8080，后端 Spring Boot 也常占 8080，端口必然冲突。所以 vue.config.js 里一般会把前端端口改成 8081，并用 proxy 把/api前缀的请求转发到后端：

// vue.config.js module.exports = { devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, pathRewrite: { '^/api': '' } } } } }

关键在 pathRewrite。'^/api': ''的意思是把请求路径里开头的/api去掉再转发。浏览器请求localhost:8081/api/login，devServer 转发给后端的是localhost:8080/login。但后端 Controller 如果定义的接口路径本身就带/api，这个剥掉/api的操作反而会让请求 404。所以你在联调前要先看一眼后端 Controller 的 RequestMapping。后端接口带/api，就把 pathRewrite 整行删掉。这是联调期最高发的路径不一致问题，后面避坑章节会再说。

代理原理其实不复杂：浏览器只认 8081 端口，8081 把请求悄悄转给 8080，端口相同所以不触发同源策略。如果用 baseURL 直接指到 8080，就需要后端开启 CORS。一个后端全局跨域配置长这样：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOrigins("http://localhost:8081") .allowedMethods("GET", "POST", "PUT", "DELETE"); } }

allowedOrigins 里我特意不写*，因为在携带 cookie 的情况下，通配符会导致认证信息被浏览器拦掉。开发环境用代理更省事，生产环境用 nginx 做转发，两种方式都干净。

4.3 vue打包放进springboot的完整操作

开发环境联调没问题后，就到了打包部署环节。最常见的做法是把 Vue 构建产物放进 Spring Boot 的 static 目录，让一个 jar 包同时托管后端接口和前端静态资源。流程分三步：

cd frontend npm install npm run build

npm install 慢是家常便饭，先换镜像再装会舒服很多：

npm config set registry https://registry.npmmirror.com

构建完成后 frontend 下会出现 dist 目录，把 dist 里的文件全部复制到：

backend/src/main/resources/static/

然后重新打包后端：

cd ../backend mvn clean package -DskipTests java -jar target/*.jar

浏览器访问http://localhost:8080，如果能直接看到登录页，说明静态资源被正确托管了。此刻已经不存在跨域问题，因为前端页面的请求路径同源。

但有一个坑在等着：Vue Router 的 mode。router/index.js 里如果写了mode: 'history'，打包进 Spring Boot 后，直接访问http://localhost:8080/order/list会 404。原因是 history 模式依赖服务器对前端路由做回退转发，Spring Boot 默认不认这个路径。解决方式两个：把 mode 改成 hash，URL 带个#号，但不会 404；或者在后端加一个转发 Controller，把所有非接口路径转发到 index.html。毕业设计演示我用 hash 就够，省心。

5. 避坑清单：物流系统跑不通的5个高频位置

我陪人跑这类系统时，发现报错集中在少数几个位置。它们有一个共性：报错信息看起来吓人，但根子往往是配置、版本和路径。把这几条记下来，能少走一半弯路。

5.1 Access denied for user：不是密码错，是插件不认账

现象：后端启动后调用登录接口，控制台抛Access denied for user 'logistics'@'localhost'。第一反应是去改密码，改完还是同样报错。

原因：MySQL 8 默认使用 caching_sha2_password 认证插件，而项目里的驱动或账号要求的是老的 mysql_native_password。还有一种可能：application.yml 里密码没加引号，YAML 把Logistics@2024里的特殊字符解析错了。

解决：先在 application.yml 里把密码用双引号包起来；如果还不行，进 MySQL 命令行把账号认证方式改回来：

ALTER USER 'logistics'@'localhost' IDENTIFIED WITH mysql_native_password BY 'Logistics@2024'; FLUSH PRIVILEGES;

MySQL 5.7 默认就是老插件，很少遇到这个问题；8.0 下才常见。改完重启后端即可。

5.2 node-sass安装失败：Node版本和前端依赖打架

现象：npm install 跑到一半，红字报node-sass下载失败，后面跟着一串gyp ERR! stack。

原因：node-sass 是 C++ 原生模块，安装时会针对当前 Node 版本下载对应的二进制。Node 18 环境下装一个为 Node 14 编译的 node-sass，编译阶段直接失败。国内网络下载 GitHub 上的二进制文件也常超时。

解决：用 nvm 把 Node 切回版本匹配的节点，然后删掉 node_modules 重新装：

nvm install 14.21.3 nvm use 14.21.3 rm -rf node_modules npm config set registry https://registry.npmmirror.com npm install

换 Node 版本比改 package.json 里的依赖版本更可控。如果你不想换 Node，可以尝试把依赖里的 node-sass 换成 sass，但两者 API 有差异，代码改动量不可控，不建议答辩前折腾。

5.3 中文全部变成问号：三个层面的字符集都要对齐

现象：登录正常，订单列表里的发货人、收货人全是???。

原因：字符集有三层——MySQL 服务端、数据库、JDBC 连接。任何一层不是 utf8，中文就会出问题。常见场景是 Linux 服务器上 MySQL 的 character_set_server 服务端默认是 latin1，建库时又没显式指定字符集。

解决：进 MySQL 查看当前字符集：

SHOW VARIABLES LIKE 'character_set%';

看到 latin1 就执行：

SET GLOBAL character_set_server = utf8mb4;

同时确认 JDBC URL 带了characterEncoding=utf8。已经写进库里的乱码数据无法通过改配置修复，必须重建表和重新导入。所以建库时指定 utf8mb4 才是唯一正确姿势。

5.4 前端页面打不开但后端正常：代理路径匹配不上

现象：后端 Tomcat started、前端 npm run serve 也正常，浏览器打开登录页输入账号，Network 面板里的请求返回 404。

原因：vue.config.js 的 pathRewrite 把/api剥掉后，和后端 Controller 的真实路径对不上。比如后端接口是/api/login，前端请求的也是/api/login，但代理剥掉前缀后转发成了/login，后端 404。

解决：用 curl 探一下后端接口真实路径：

curl http://localhost:8080/login

有返回说明接口真在/login，代理配置正确；返回 404 再试：

curl http://localhost:8080/api/login

后端带/api就在 vue.config.js 里删掉 pathRewrite 那行。我在项目里通常给后端 Controller 统一加/api前缀，代理只转发不重写，两边口径一致，这类问题直接消失。

5.5 Invalid bound statement：Mapper接口有但XML没扫到

现象：后端启动正常，点击订单列表接口时控制台报Invalid bound statement (not found)。

原因：MyBatis 的 Mapper 接口类被 Service 调用了，但对应的 XML 映射文件不在扫描路径里。常见于打包环境，IDEA 编译时把 XML 文件漏掉了。

解决：确认 application.yml 里有：

mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml

再检查 target/classes 目录下有没有 mapper 文件夹。如果你发现 XML 和接口类放在同一个 java 包目录下，需要在 pom.xml 里加一段资源声明：

<build> <resources> <resource> <directory>src/main/java</directory> <includes> <include>**/*.xml</include> </includes> </resource> </resources> </build>

如果 XML 本来就放在 resources/mapper 下，这段通常可以不加。问题根源始终是“接口找到了，XML 没找到”，排查顺序按这个思路来最快。

6. 论文、答辩与上线验证：从“能运行”到“能演示”

系统能跑只是第一步，带着论文去答辩、给老师现场演示，才是这套毕业设计真正过关的标志。

6.1 论文里必须与代码对得上的4处

论文不是摆设，答辩时老师随机抽问，对不上就露馅。我建议答辩前把四个环节逐一核对：

不一致时以代码为准改论文。数据库表结构一旦定了要改就要清数据，论文文档随时能改，别反着来。

6.2 上线部署与参数覆盖

演示环境我建议直接用 jar 包配合前端 dist 目录。后端打包后，命令行启动时用参数覆盖敏感配置，避免把正式密码暴露在 application.yml 里：

nohup java -jar logistics.jar \ --spring.datasource.username=logistics \ --spring.datasource.password=Logistics@2024 \ > app.log 2>&1 &

nohup 保证退出终端后进程不中断，> app.log 2>&1把标准输出和错误输出都写进日志。实时日志用tail -f app.log查看。

6.3 验收演示时的流程与命令

答辩前用 curl 验证主链路，确保接口不会当众出丑：

# 1. 登录拿token curl -X POST http://localhost:8080/api/login \ -H 'Content-Type: application/json' \ -d '{"username":"admin","password":"123456"}' # 2. 带token查订单列表 curl http://localhost:8080/api/order/list \ -H 'Authorization: Bearer <上一步返回的token>'

如果登录接口不是 JSON 格式而是表单，把 Content-Type 改成application/x-www-form-urlencoded即可。演示时按业务闭环走：创建订单 → 分配车辆 → 状态改为运输中 → 签收。这条链路走通，等于把前端页面、后端接口、数据库状态流转三层交互全部演示了一遍，比随机点菜单有说服力得多。

我带人跑这类项目这么多年，印象最深的翻车从来不是业务逻辑，而是环境：端口被占、版本不对、路径不一致。拿到这套物流管理系统，我建议你先跑通最小闭环，再去抠页面细节——主线通了，后面都是锦上添花。希望帮到你。

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