简介：基于 SSM 框架与 JSP 技术的网上电子书店管理系统源码项目，面向 Java Web 初学者和毕业设计、课程设计人群，实现前台电子书浏览与展示、通知公告、留言反馈、个人中心、在线客服，以及后台图书管理等完整功能。压缩包共 1297 个文件，大小约 30.57MB，含 Java 后端源码、JSP 动态页面、脚本、样式、图片等前端资源，同时提供完整 SQL 脚本、XML 配置、Maven 工程文件和说明文档。项目整体采用 Maven 构建，整合 Spring 系列框架与 MySQL 数据库，配套数据库管理工具，是一套典型的三层架构项目；已有 66 人学习下载。通过研读源码可掌握前后台交互流程、MVC 分层设计、持久层映射编写和页面渲染等关键技能，也可借助数据库脚本在常用 IDE 中导入运行，适合用于完整项目复盘、二次开发，或改造成自己的课程设计/毕业设计。

1. 这套 SSM 电子书店源码，解决的是“从零憋毕设还是拆真实项目”的选择题

如果只拿“Java + JSP + SSM + MySQL”去搜资源，你大概率会翻到两类东西——一类是只有控制器和 Mapper 的残缺半成品，另一类是文档漂亮但一跑就报 404 的“演示版”。这套网上电子书店源码属于第三类：它更像一个从 IDE 建项到数据库落盘到前台页面全链路能跑通的教学型完整工程，适合正在做 Java Web 课程设计、准备 SSM 方向面试、或者想找一个“不花哨但五脏俱全”的 CRUD 商业案例来练手的人。它的技术选型不新，但这恰恰是它的价值：Spring、SpringMVC、MyBatis 三件套在中小企业项目里依然是存量主流，你面试时被追问的也大概率还是这套东西。这里不绕弯子，直接把拆包下来的工程结构、关键映射关系、数据库设计思路、以及我自己跑起来时踩过的坑全部摊开讲。

2. 工程结构与 SSM 整合：先搞清楚每个目录存在的意义

拿到源码包第一件事，不是双击pom.xml，而是先按目录结构把“谁负责什么”映射到脑子里。这里我用 IDEA 打开工程后的典型布局如下：

• src/main/java：后端 Java 源码，按 controller、service、mapper、entity 分包；
• src/main/resources：Spring 配置文件、MyBatis 映射 XML、数据库连接配置；
• src/main/webapp：JSP 页面、静态资源（CSS、JS、图片）、WEB-INF/web.xml；
• src/main/webapp/WEB-INF/views：通常存放受保护的 JSP，不允许直接 URL 访问；
• sql/：初始化数据库脚本；
• pom.xml：Maven 依赖与构建配置。

这个分层对应的是 SSM 的标准套路：DispatcherServlet接收请求，HandlerMapping根据 URL 找到Controller，Controller调Service，Service走Mapper接口，Mapper绑定 XML 里的 SQL 操作 MySQL。

2.1 Spring 与 SpringMVC 的容器配置不要写成一锅粥

SSM 整合里最容易被忽略的，是 Spring 和 SpringMVC 的容器职责划分。applicationContext.xml管理 Service、Dao、事务、数据源，spring-mvc.xml只管 Controller、视图解析器、静态资源映射和注解驱动。两者如果混淆，比如把<context:component-scan>配在 SpringMVC 配置里且扫描了com.xxx.service，会导致事务失效——因为 Service 被 SpringMVC 子容器提前加载，Spring 父容器里的事务代理不会作用到这批实例上。

这套电子书店源码里，常见的正确姿势是这样的：

<!-- applicationContext.xml --> <context:component-scan base-package="com.bookstore.service" /> <bean id="dataSource" class="org.apache.commons.dbcp2.BasicDataSource"> <property name="driverClassName" value="com.mysql.jdbc.Driver" /> <property name="url" value="jdbc:mysql://localhost:3306/bookstore?useUnicode=true&amp;characterEncoding=utf8" /> <property name="username" value="root" /> <property name="password" value="123456" /> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource" /> <property name="mapperLocations" value="classpath:mapper/*.xml" /> </bean>

<!-- spring-mvc.xml --> <mvc:annotation-driven /> <mvc:resources mapping="/static/**" location="/static/" /> <context:component-scan base-package="com.bookstore.controller" /> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/views/" /> <property name="suffix" value=".jsp" /> </bean>

注意这里mvc:resources解决了 JSP 项目里静态资源被前端控制器拦截的问题。如果你在部署时发现首页样式全丢，90% 是这一行缺失或路径前缀对不上。数据库连接串必须加characterEncoding=utf8，否则中文书名存入 MySQL 后读取会是乱码；我在排错时还发现有的电脑上需要追加serverTimezone=Asia/Shanghai才能过 MySQL 8.x 的驱动校验，MySQL5.7 则不需要。

2.2 Maven 的依赖版本收敛：JSP 项目翻车的重灾区

pom.xml里最怕的不是少依赖，而是版本冲突导致NoSuchMethodError或ClassNotFoundException。这套项目里我用到的核心依赖及兼容版本如下：

有个血泪经验：javax.servlet-api记得设为<scope>provided</scope>，不然最后打 WAR 包时 Tomcat 会和依赖里的servlet-api冲突，直接抛java.lang.LinkageError。另外一个坑是 mybatis-spring 2.x 对 Spring 5 支持没问题，但如果你本地是 Spring 4.x，必须退回 mybatis-spring 1.3.x，否则启动时SqlSessionFactoryBean会报找不到setSqlSessionFactoryBeanName方法。

依赖树检查常用命令：

mvn dependency:tree -Dincludes=org.springframework:spring-core mvn clean package -DskipTests

如果构建时下载依赖卡死，换阿里云镜像源比反复重试靠谱。在~/.m2/settings.xml里配置 mirror，中央仓库在国内访问确实不稳定。

3. 数据库设计到业务闭环：从建表 SQL 里反推系统功能

这套电子书店系统的核心数据表不算复杂，但足够典型。我拆包时看到 SQL 文件里至少包含用户表、书籍信息表、分类表、订单表、订单项表、通知公告表、留言反馈表这几张。它们之间的外键关系决定了页面上的“点击分类查书”“下单扣库存”这些操作要怎么写。

3.1 书籍表与分类表的设计：为什么用逻辑外键而非数据库外键

图书表books的核心字段我会这样设计：

CREATE TABLE `t_book` ( `id` INT AUTO_INCREMENT PRIMARY KEY, `category_id` INT NOT NULL COMMENT '分类ID，逻辑外键', `book_name` VARCHAR(100) NOT NULL, `author` VARCHAR(50), `isbn` VARCHAR(20), `price` DECIMAL(10, 2), `cover_url` VARCHAR(255), `pdf_url` VARCHAR(255), `description` TEXT, `click_count` INT DEFAULT 0, `create_time` DATETIME ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

category_id用逻辑外键而不用FOREIGN KEY约束，是 SSM 项目里的常见做法。原因有二：一是 MyBatis 做关联查询时自己控制 JOIN SQL 更灵活，物理外键反而限制分页查询的性能；二是这类教学项目在后台管理里删除分类时，通常要“软处理”——就是先检查该分类下有没有书，有书的话提示不能删。逻辑外键可以把这个校验放在 Service 层完成，比数据库抛外键异常更好处理。

后端查询某分类下的图书列表时，Mapper XML 里是这么写的：

<select id="selectBooksByCategoryId" resultType="com.bookstore.entity.Book"> SELECT id, book_name, author, price, cover_url, click_count FROM t_book WHERE category_id = #{categoryId} ORDER BY click_count DESC LIMIT #{offset}, #{limit} </select>

offset和limit是分页参数，Service 层要自己计算：offset = (pageNum - 1) * pageSize。这套代码没有引入 PageHelper 插件，属于“裸写分页”，好处是你能看清 LIMIT 本质，坏处是每张表的分页都要重复写一遍，但这个对于看懂原理来说反而是优点。

3.2 订单与库存的扣减逻辑：什么时候该用事务

用户在前台下单，涉及t_order插入订单主表、t_order_item插入订单项表、t_book更新库存（本书没有真实库存，但加了stock字段模拟减量）。三步操作必须保证原子性。源码里典型的写法是在 Service 实现类上加@Transactional：

@Service public class OrderServiceImpl implements OrderService { @Transactional(rollbackFor = Exception.class) @Override public boolean createOrder(OrderDTO dto, Integer userId) { Order order = new Order(); order.setUserId(userId); order.setOrderNo(generateOrderNo()); order.setTotalAmount(dto.getTotalAmount()); orderMapper.insert(order); for (OrderItemDTO item : dto.getItems()) { OrderItem orderItem = new OrderItem(); orderItem.setOrderId(order.getId()); orderItem.setBookId(item.getBookId()); orderItem.setQuantity(item.getQuantity()); orderItem.setPrice(item.getPrice()); orderItemMapper.insert(orderItem); // 扣减库存，UPDATE 语句自带行锁 int affected = bookMapper.decreaseStock(item.getBookId(), item.getQuantity()); if (affected == 0) { throw new RuntimeException("库存不足，订单回滚"); } } return true; } }

这里的关键细节在bookMapper.decreaseStock的 SQL 写法上：

<update id="decreaseStock"> UPDATE t_book SET stock = stock - #{quantity} WHERE id = #{bookId} AND stock >= #{quantity} </update>

WHERE stock >= #{quantity}是防超卖的关键，它让数据库在更新时就判断库存是否充足，返回影响行数为 0 说明库存不够，直接抛异常触发事务回滚。如果你先SELECT stock再在 Java 里判断库存，那高并发下必出超卖。这一点面试时被问“你怎么保证数据一致性”可以直接拿这个例子回答。

3.3 通知公告与留言反馈：一张表如何同时支撑两个功能

后台管理员发布的通知公告，和普通用户在“留言反馈”页提交的咨询，在很多简化项目里是共用一个messages表的，区别在于一个type字段：1表示公告、2表示用户留言。这样前台首页“通知公告”列表和“留言反馈”列表查询时，只需要在 Service 层传入不同的 type 值即可。

这种设计教学价值大于实用价值，真正商用会把公告和留言拆成两张表，因为公告需要置顶、定时发布等扩展字段。但作为课程设计，这种“一张表两用”的巧思反而能写进说明文档里，向答辩老师证明你具备数据归类意识。

4. JSP 前端页面的数据渲染：从 EL 到 JSTL 的完整链路

这套项目的前端是 JSP，不是前后端分离。它用 EL 表达式和 JSTL 标签把后端ModelAndView里塞的数据循环渲染到 HTML 上。拆开index.jsp，你能看到一套非常经典的“首页轮播 + 分类入口 + 热门图书排行 + 最新公告”布局。

4.1 首页图书列表的 JSP 写法：避免 Scriptlet 的恶劣味道

先把结论放这：这套源码里没有大段<% %>写 Java 代码的情况，都是用 EL 和 JSTL，说明项目规范程度尚可。一个典型的图书列表块长这样：

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %> <div class="book-grid"> <c:forEach var="book" items="${hotBooks}"> <div class="book-item"> <a href="${pageContext.request.contextPath}/book/detail/${book.id}"> <img src="${pageContext.request.contextPath}${book.coverUrl}" alt="${book.bookName}" /> <h3>${book.bookName}</h3> <p>作者：${book.author}</p> <span class="price">￥<fmt:formatNumber value="${book.price}" pattern="0.00"/></span> <c:if test="${book.stock <= 0}"> <span class="stock-tip">暂时缺货</span> </c:if> </a> </div> </c:forEach> </div>

${pageContext.request.contextPath}是 JSP 里最稳的获取上下文路径的方式。新手经常直接写/static/xxx或href="/book/detail"，本地起在 8080 端口没感觉，一但打成 WAR 包部署到 Tomcat 的/bookstore路径下，所有绝对路径全部 404。路径问题在 JSP 项目里占到报错原因的 30% 以上，用c:url标签也行，但contextPath前缀是最直白的。

fmt:formatNumber的作用是把29.9这种数值格式化成29.90，避免出现用户看到价格少一位的尴尬。这些都属于“能跑但体验差”和“跑得好且像真实商城”的区别。

4.2 图书详情页的动态参数传递：URL 重写与请求转发

点击首页图书，进入详情页book/detail/${book.id}，Controller 端对应的写法是：

@Controller @RequestMapping("/book") public class BookController { @Autowired private BookService bookService; @RequestMapping("/detail/{id}") public String detail(@PathVariable("id") Integer id, Model model) { Book book = bookService.getBookById(id); bookService.increaseClickCount(id); model.addAttribute("book", book); // 推荐同类图书 List<Book> recommend = bookService.getBooksByCategoryExcludeSelf(book.getCategoryId(), id, 4); model.addAttribute("recommendBooks", recommend); return "book/detail"; } }

@PathVariable拿 URL 里的 id，Service 查库，把 Book 对象塞进 Model，转发到book/detail.jsp渲染。这里的increaseClickCount和“推荐同类图书”是本项目的两个体验小亮点——前者在书详情页展示“xx 人看过”增加真实感，后者在没有协同过滤的情况下用“同分类随机四本”做了最朴素的相关推荐。

这种推荐逻辑对一个课程设计来说是恰到好处的：不引入 Redis 做实时计数，也不上 Mahout 做算法推荐，复杂度控制在“能讲清楚 SQL 和循环”的范围内。如果你要升级，我会建议把点击数量改成每 10 分钟批量 UPDATE 一次，避免每次刷新都写库——这个优化点可以在答辩时作为“未来展望”提。

4.3 后台管理页面的角色区分：登录拦截器的过滤范围

普通用户在前台登录后能进“个人中心”，管理员能进“后台管理”。源码里实现这个用的是 SpringMVC 拦截器。拦截器注册配置：

<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/admin/**"/> <bean class="com.bookstore.interceptor.AdminAuthInterceptor"/> </mvc:interceptor> <mvc:interceptor> <mvc:mapping path="/user/**"/> <mvc:exclude-mapping path="/user/login"/> <mvc:exclude-mapping path="/user/register"/> <bean class="com.bookstore.interceptor.UserAuthInterceptor"/> </mvc:interceptor> </mvc:interceptors>

这里最容易被绕过的坑是：/admin/**匹配不到/admin这个精确路径，需要在<mvc:mapping>里额外加一条/admin。我在检查中发现这类问题很典型，就是页面跳转return "admin/index"时视图解析器拼出/WEB-INF/views/admin/index.jsp，但 URL 路径是/admin/index，直接访问/admin会被 Tomcat 302 到某地址，如果拦截器路径没覆盖就等于裸奔。

拦截器里判断登录状态的核心逻辑：

public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object adminUser = request.getSession().getAttribute("adminUser"); if (adminUser == null) { response.sendRedirect(request.getContextPath() + "/admin/login"); return false; } return true; }

4.4 前台首页的富文本和公告：后端如何给 JSP 供数

前台公告栏和留言反馈板块属于相对独立的模块。公告列表的 SQL 通常按创建时间倒序取前 5 条，Controller 里：

@RequestMapping("/") public String index(Model model) { List<Book> hotBooks = bookService.getHotBooks(8); List<Book> newBooks = bookService.getNewBooks(8); List<Notice> notices = noticeService.getLatestNotices(5); List<Category> categories = categoryService.getAllCategories(); model.addAttribute("hotBooks", hotBooks); model.addAttribute("newBooks", newBooks); model.addAttribute("notices", notices); model.addAttribute("categories", categories); return "index"; }

return "index"配合视图解析器的prefix/suffix，最终渲染的是WEB-INF/views/index.jsp。用户看起来访问的是项目根路径/，实际物理路径藏在WEB-INF下，这也是 JSP 项目的经典安全设计：外部不能直接输入.jsp连接访问到页面文件。

5. 部署与运行避坑指南：我从源码包到跑通的真实排错记录

这一章的每条坑都是我在 IDEA 中实际搭建这套环境时遇上的。按“现象 → 原因 → 解决”拆开，确保你照着做就能少踩雷。

5.1 坑一：Tomcat 启动后立刻报ClassNotFoundException: DispatcherServlet

现象：catalina.out日志或 IDEA 控制台抛java.lang.ClassNotFoundException: org.springframework.web.servlet.DispatcherServlet，WAR 根本发布不成功。

原因：Maven 的spring-webmvc依赖未被包含进部署产物。直接启动 IDEA 时，Tomcat 加载的是target目录里的依赖，而不是本地 Maven 仓库，如果 WEB-INF/lib 下没有对应 jar 包就抛这个类不存在异常。

解决：双击 Maven 面板的clean，再package，然后重点检查target/xxx/WEB-INF/lib下有没有spring-webmvc-*.jar。没有的话执行：

mvn dependency:copy-dependencies -DoutputDirectory=src/main/webapp/WEB-INF/lib

或者更干净的做法——确认 pom 里没把依赖设成<scope>provided</scope>。provided表示容器提供，Tomcat 里如果没装对应插件，类肯定找不到。

5.2 坑二：数据库连不上，Communications link failure

现象：启动 Spring 容器时，BasicDataSource初始化连接 Mysql 报Communications link failure. The last packet sent successfully to the server was 0 milliseconds ago.

原因：最常见的是 MySQL 服务没启动；其次是 MySQL8.0 和 MySQL5.7 的驱动类名不同：5.7 用com.mysql.jdbc.Driver，8.0 需要换成com.mysql.cj.jdbc.Driver，并且 URL 追加serverTimezone=Asia/Shanghai。如果本地装的是 MySQL8 而源码里写的是 5.7 的驱动，同样连不上。

解决：先用 SQLyog 或 Navicat 手动连接一次，排除账号权限问题。然后确认jdbc.properties配置：

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/bookstore?useUnicode=true&characterEncoding=utf8&useSSL=false jdbc.username=root jdbc.password=123456

如果本机 MySQL 版本是 8.x，把驱动类和 url 改成本段开头说的那套。

5.3 坑三：JSP 页面渲染中文乱码

现象：页面上的书名、作者全是???或乱码。

原因：三层乱码叠加——数据库表字符集不是 utf8mb4、JDBC 连接串没指定characterEncoding=utf8、JSP 页面本身没声明pageEncoding。这三层必须全部正确。

解决：把三处全部统一：

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>

修改 Tomcat 的server.xml，在<Connector>里加URIEncoding="UTF-8"。数据库方面用 Navicat 把表结构改成 utf8mb4，已存在的乱码数据只能删掉重建。

5.4 坑四：后台管理页面 No mapping found for HTTP request with URI [/admin/index]

现象：输入/admin/index访问后台首页，控制台打印No mapping found for HTTP request with URI [/admin/index] in DispatcherServlet，然后 404。

原因：AdminController只写了@RequestMapping("/admin")没有写子路径，或视图转发的前缀拼错了。比如return "admin/index"如果模板文件是webapp/WEB-INF/views/admin/index.jsp，这一般是正确的。问题往往出在控制器类上标记了@RequestMapping("/admin")，方法里的@RequestMapping("/index")没有映射成功，或者是拦截器把带/admin的GET /admin请求在 preHandle 里直接放过了，但 Controller 没有对应处理根路径的@RequestMapping，导致 404。

解决：在控制器类里加一个根路径映射：

@Controller @RequestMapping("/admin") public class AdminController { @RequestMapping({"", "/", "/index"}) public String index() { return "admin/index"; } }

让/admin、/admin/、/admin/index三个 URL 都落到同一个方法。这种兼容写法是我在多个 JSP 项目里验证过的最稳方案。

5.5 坑五：前端页面 CSS 生效，JS 不生效或反过来

现象：页面布局正常但下拉菜单无反应，或者个别按钮点击没事件。

原因：JSP 页面底部有<script src="${pageContext.request.contextPath}/static/js/setMenu.js"></script>，但spring-mvc.xml里只映射了/static/**到/static/，JS 文件路径如果写成了js/setMenu.js而非static/js/setMenu.js，就会被 DispatcherServlet 当成 Controller 请求处理，返回 404。

解决：部署后打开浏览器开发者工具（F12）的 Network 面板，逐个检查 JS 请求的响应状态。是 404 就把路径改对，特别注意大小写。JSP 项目里路径大小写敏感，SetMenu.js和setMenu.js在 Linux 服务器上是两个文件，在 Windows 上可能没问题，而一旦部署到云服务器就翻车。

6. 把 IDEA 里的项目打成 WAR 包部署到 Tomcat 的完整操作链路

最后这一章我觉得很有价值，因为很多资料默认你只在 IDEA 内置 Tomcat 里点“绿色三角形”运行，但这和真正的部署交付完全是两回事。本资源涉及的 JSP 传统项目打 WAR 包部署，操作链路如下。

6.1 修改 pom.xml 的打包方式

确认pom.xml的 packaging 是 war：

<packaging>war</packaging> <build> <finalName>bookstore</finalName> </build>

finalName决定 WAR 包解压后的目录名。设成bookstore后，部署到 Tomcat 的webapps目录下，访问路径就是http://localhost:8080/bookstore/。这一步如果不管，默认的包名带着版本号如bookstore-1.0,URL 上多个尾巴，歧义很多。

6.2 用 Maven 命令打出可直接部署的 WAR

我一般习惯不用 IDEA 的图形化按钮，直接在 Maven 面板里敲命令，输出更干净，出错信息也更直观：

mvn clean package

如果测试代码不完整导致打包失败，跳过测试再打：

mvn clean package -DskipTests

打包完成后，target/bookstore.war出现在工程目录。这时不要急着扔进 Tomcat——先解压检查一下WEB-INF/lib里有没有 MySQL 驱动 jar。没有的话，运行时数据库连接会报ClassNotFoundException: com.mysql.jdbc.Driver，解决办法是在 pom 里确认驱动依赖没有<scope>provided</scope>。踩过这坑的人都知道要养成打包后习惯性看一眼依赖目录的习惯。

6.3 部署到本机 Tomcat 并解决 context path 问题

把bookstore.war拷贝到 Tomcat 的webapps目录，Windows 下双击bin/startup.bat，Linux 下bin/startup.sh。Tomcat 会自动解压 WAR 包，生成同名目录。

这时访问http://localhost:8080/bookstore/，首页能出。但如果你看到 CSS 全部丢失，点登录跳 404，回忆上文提到的路径内容，检查是否所有 JSP 里的链接都带了contextPath前缀。这里提供一个通用的排查方法：

curl -I http://localhost:8080/bookstore/static/css/style.css

如果返回 200，说明静态资源映射正常；403 说明目录被拒，404 说明路径错误。我在排查时就发现/bookstore/static/css/style.css有映射而 js 路径不对的混合情况，最终统一在 JSP 顶部声明：

<c:set var="ctx" value="${pageContext.request.contextPath}" />

然后后续所有静态资源和链接都用${ctx}前缀。这个习惯保持到现在，已成了我在 JSP 项目里解决路径问题的第一个动作。

6.4 伪部署验证：启动后立刻检查日志三段

日志差不多是这几个阶段：

• INFO: Starting Servlet Engine: Apache Tomcat/8.x.x——Tomcat 启动完成；
• DEBUG ch.qos.logback...或 MyBatis 打印 Mapper XML 注册信息——Spring 容器加载完成；
• INFO: Server startup in [xxxx] milliseconds——启动成功无异常。

如果你看到SEVERE级别日志，先看异常栈顶部，是我第 5 章提到的就往那个方向排。如果startup.bat一闪而过，打开 Tomcat 的logs/catalina.out或logs/localhost.log看崩溃原因。这里我多嘴说一句：把 IDE 的 console 关掉后在 Tomcat 目录下用命令行启动，日志重定向输出到文件，排查效率高得多：

cd /path/to/tomcat/bin ./startup.sh tail -f ../logs/catalina.out

从那以后，我不管拿到什么 Java Web 老项目，都会先启动一次、打一次完整日志、检查一次 WEB-INF/lib 依赖是否齐全，走完这三步再动代码。这样能避开八成环境类问题，也少去猜别人的代码“为什么跑不起来”。这套资源会默认你懂一点 Maven 和 Tomcat 的基础，但只要你按上面的顺序把环境配好，重点去读 Controller 的跳转逻辑和 Mapper XML 的 SQL，收获会比单纯做页面大得多。希望帮到你。

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