企业官网建设流程全解析

SSM+Java的商店管理系统，放在最近几年的毕业设计选题里，依然是出场率最高的那一档。原因很朴素：技术栈经典、网上资料多、业务逻辑完整、论文好写，而且答辩的时候有得讲。不管是商品管理、订单流转还是库存扣减，每块功能都能对应到一个明确的技术点，老师问起来你至少能接得住。

这篇不是给你贴一堆百度能搜到的“系统介绍”，而是直接把这类项目拆开讲透：数据表怎么设计、核心代码怎么组织、事务和库存怎么处理、论文结构怎么排、哪些坑是每年都会有人踩的。正在做SSM毕设、或者打算做商店/商城类系统但还没定题的同学，照着这篇理顺思路，比闷头抄一份源码要有用得多。

1. 项目整体设计与选题思路

1.1 为什么SSM商店管理系统是“稳”的选择

毕设选题通常有三条路线：一是纯前端加模拟数据，二是前后端分离加Spring Boot，三是沿用SSM做传统Java Web项目。对大多数要兼顾找工作、考研、写论文的本科生来说，SSM商店管理系统几乎是性价比最高的选择。

原因有几个。第一，SSM的架构分层非常清晰，Controller、Service、Dao三层各管一摊，评委老师看代码结构就能看出你“学过软件工程”。第二，商店类业务天然覆盖了增删改查、多表关联、事务控制、权限管理、数据统计这些高频考点，一套系统做完，知识点清单就很完整了。第三，SSM虽然看起来老，但Spring、SpringMVC、MyBatis这几个框架的底层思想至今没有变，学明白这套再去碰Spring Boot，迁移成本很低。

我自己见过不少同学，选了个花里胡哨的“智慧校园系统”，结果技术点撑不起来，论文只能大量抄概念。商店管理系统的好处在于：越简单的东西越容易做扎实，你把商品、购物车、订单、库存这条业务链跑通，比什么都强。

1.2 SSM三框架的分工：一个生活化类比

很多新手搞不清楚SSM到底在干什么，最后写代码的时候把JDBC代码写在Controller里，那就失去了SSM的意义。用一个类比来理解：

Spring像是一个“后勤管家”，负责创建和管理所有对象的生命周期。你不需要在代码里一遍遍new对象，全部交给Spring容器去实例化、装配、销毁。这在大量Service、Dao互相依赖的时候，能省掉非常多重复的初始化代码。

SpringMVC就是“前台接待员”，所有HTTP请求先到FrontController，它帮你解析URL、把请求参数封装成Java对象、调用对应的业务类，最后再把业务处理结果渲染成页面返回给浏览器。它解决了Java Web里最杂乱的那个环节——请求分发和跳转。

MyBatis则像“仓库记账员”，它封装了JDBC那套繁琐的Connection、Statement、ResultSet操作。你只需要写SQL语句和映射关系，MyBatis负责把数据库表记录自动映射成Java对象，或者把Java对象参数绑定到SQL里。

三者串起来就是一次完整的请求处理链：浏览器发请求 → SpringMVC接收 → 调用Service业务逻辑 → Service操作MyBatis查询数据库 → 结果返回到Controller → 渲染JSP页面 → 浏览器展示给你。

1.3 系统角色的权限设计：不要一上来就上Shiro

商店管理系统涉及的角色一般有两种：管理员和普通收银员或销售员。很多同学看到“权限管理”这个词，就想着集成Spring Security或者Shiro，结果配置半天没跑通，反而把自己绕进去。

真实的毕业设计项目，用Session加拦截器就够了。用户登录后把用户信息放入Session，定义好哪些URL需要管理员权限，哪些只需要登录即可访问。拦截器在请求处理之前检查Session里有没有对应的角色标记，没有就跳转到登录页。这个方案完全能满足商店系统的权限需求，而且代码量小、逻辑一眼能看明白，论文里也好解释。

如果你非要用Shiro，我也不是拦着你，只是提醒：你要保证自己能在答辩现场讲清楚Shiro的Subject、SecurityManager、Realm三个核心概念。讲不清楚的话，反而成了减分项。功能服务于卖点，别为了炫技给自己挖坑。

2. 数据库设计与业务建模

2.1 核心数据表：最小集是6张，不是越多越好

数据库设计是论文评审重点关注的一环。商店管理系统最核心的表，我个人建议保持这几张：

• t_user（用户表）：用户ID、用户名、密码、真实姓名、角色、创建时间
• t_category（商品分类表）：分类ID、分类名称、父分类ID、排序
• t_product（商品表）：商品ID、分类ID、商品名称、单价、市场价、库存量、图片、描述、上下架状态
• t_order（订单表）：订单ID、订单编号、用户ID、总金额、收件人信息、订单状态、下单时间、支付时间
• t_order_item（订单明细表）：明细ID、订单ID、商品ID、购买数量、商品快照单价、小计金额
• t_cart（购物车表）：记录ID、用户ID、商品ID、数量、加入时间

有些同学会把库存量单独拆一张库存表，大可不必。商店管理系统的库存逻辑还远没到需要独立库存模型的复杂程度，商品表里直接加一个stock字段就够了。表越少，外键关系越简单，写SQL的时候你越轻松。

2.2 字段设计里的三个“过来人”提醒

第一，金额字段一定要用DECIMAL类型，比如DECIMAL(10,2)，不要用FLOAT或DOUBLE。浮点数在计算机里是不精确的，算总价、算利润的时候会出现零点几分的误差，这在答辩现场演示的时候会非常尴尬。第二，密码字段至少要加密存储。不需要上太复杂的算法，MD5加盐或者SHA-256都行。论文里写上“系统对用户密码采用加密算法处理，防止明文泄漏”，这是一个非常拿得出手的安全卖点。第三，所有表都建议加上create_time和update_time两个时间字段，后续统计报表、排查数据问题都用得上，还显得你设计规范。

分类表和商品表是典型的“一对多”关系，订单表和订单明细表是经典的“一主多从”结构。论文里的ER图就用这层关系来画，不要画得比蜘蛛网还复杂，清晰关系本身就是得分点。

2.3 订单状态流转：整个系统里最值得讲清楚的设计

订单模块最容易被忽略的是状态设计。一个完整的订单状态机应该是：

待支付 → 已支付 → 已发货 → 已完成，其中待支付可以转已取消，已发货之前也可以取消或申请退款。

落实到数据库，就是t_order表里的status字段，用一个整数表示状态：0待支付、1已支付、2已发货、3已完成、4已取消。每一次状态变更都在代码里做校验，比如待支付状态下才能执行支付操作，已发货状态下不能直接取消。

为什么专门强调这个？因为很多同学做订单模块，就写一个简单的INSERT，状态字段形同虚设。你如果把状态流转讲清楚，等于把软件工程里的状态机概念落地了一个实例，是非常容易加分的点。这里也提醒一下，如果后续想扩展售后流程，可以在状态机里再加一层退款表，但现在毕业设计做到订单状态这个粒度已经足够。

3. 核心功能拆解与实现

3.1 登录认证与拦截器：代码不多，逻辑必须严谨

登录模块看似简单，却决定了整个系统的安全底线。核心逻辑分三步：前端提交用户名和密码 → Service层校验 → 登录成功把用户对象放入Session。

需要注意两个细节。第一，查询用户时用“用户名”作为唯一查询条件，拿到结果之后再比对密码，不要用“用户名+密码”直接作为查询条件。否则如果用户不存在，你就无法区分是密码错误还是用户名不存在，从安全角度来说，等于给了攻击者试探信息。第二，密码比对要以“密文对密文”的方式，用加密后的值做校验，而不是把数据库里的密文解密后再跟明文比。像MD5这类算法本身就不是为了解密设计的。

拦截器的实现思路也很直接：自定义一个HandlerInterceptor，在preHandle方法里判断请求路径是否在排除列表里，比如登录页、登录请求、静态资源。如果用户没登录，直接重定向到登录页面。

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); if (user == null) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return false; } return true; } }

在SpringMVC配置文件里注册这个拦截器，并设置好拦截和放行的URL规则，整个权限控制的骨架就完成了。管理员和普通员工的功能区分，只需要在页面和Controller里再加一层角色判断即可。

3.2 商品管理的动态SQL：MyBatis的拿手戏

商品管理模块的核心是列表查询，往往需要支持按名称模糊搜索、按分类筛选、按价格区间筛选，以及分页。如果给每一种组合都写一条SQL，代码会变得又臭又长。MyBatis的动态SQL就是解决这个问题的。

<select id="pageQuery" resultType="com.demo.entity.Product"> SELECT * FROM t_product <where> <if test="productName != null and productName != ''"> AND product_name LIKE CONCAT('%', #{productName}, '%') </if> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="status != null"> AND status = #{status} </if> </where> ORDER BY create_time DESC </select>

你会发现<where>标签非常聪明，它会在第一个条件成立时自动加上WHERE关键字，而且能去掉条件语句开头多余的AND。这样前台传什么参数，后台就拼什么条件，一套查询走天下，不用写死SQL。

使用动态SQL时有个反模式必须提醒：拿用户输入直接用${}拼接字符串。这是经典的SQL注入漏洞，一定要全部使用#{}占位符。如果你在答辩的时候主动提一句“系统所有SQL均使用预编译绑定参数，避免SQL注入”，这个安全意识立刻能让老师眼前一亮。

3.3 购物车与订单结算：从“选商品”到“生成订单”的完整链路

购物车模块有两种做法：一种是只存在Session里，简单快捷；另一种是存入数据库表。我建议用数据库表实现，理由是：论文结构更完整、数据不丢失、可以记录不同用户的购物车状态。虽然多写几段CRUD，但对于毕设来说“完整”比“简单”更重要。

用户点击“加入购物车”时，后端要做库存预校验，如果加入数量大于库存量，直接提示库存不足。购物车页面修改数量时，也要再次校验，防止用户把数量改成9999然后前端不校验就提交。这是一个典型的“后端永远不信任前端”原则，写进论文的安全设计部分非常加分。

订单生成流程是整个系统里最需要细心处理的地方。一次订单提交要完成的事远不止INSERT一条记录：

1. 校验购物车是否有商品
2. 计算订单总金额
3. 插入t_order主表，拿到生成的主键ID
4. 遍历购物车明细，逐条插入t_order_item
5. 同步扣减t_product的库存
6. 清空该用户的购物车

这六个步骤，任何一步失败，前面的操作都不能保留，否则就会出现“订单生成了但库存没扣”或者“库存扣了但订单没建”的数据不一致问题。解决方案就是事务。

3.4 事务控制在库存扣减里的关键作用

Spring声明式事务用起来非常简单，在Service方法上加一个@Transactional注解就行。但要真正保证数据一致，有几个细节不能忽略。

第一，@Transactional要加在Service层，而不是Controller层。Controller只负责参数接收和页面跳转，事务应该作用在完整的业务方法边界上。第二，方法必须是public的，而且不能通过self-invocation调用，比如同一个类里的另一个方法调用this.order()，事务会失效，因为Spring的事务代理没有生效。第三，建议在注解里指定回滚条件，默认配置是遇到运行时异常才回滚，遇到受检异常不会回滚。稳妥的写法是@Transactional(rollbackFor = Exception.class)。

@Transactional(rollbackFor = Exception.class) public boolean submitOrder(Integer userId) { List<CartItem> cartItems = cartMapper.selectByUserId(userId); if (cartItems == null || cartItems.isEmpty()) { return false; } Order order = new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setTotalAmount(calcTotal(cartItems)); order.setStatus(0); orderMapper.insert(order); for (CartItem item : cartItems) { OrderItem detail = new OrderItem(); detail.setOrderId(order.getId()); detail.setProductId(item.getProductId()); detail.setBuyNum(item.getQuantity()); detail.setPrice(item.getProductPrice()); orderItemMapper.insert(detail); productMapper.deductStock(item.getProductId(), item.getQuantity()); } cartMapper.deleteByUserId(userId); return true; }

这段代码的核心逻辑就是“先插主表，再插明细，同时扣库存”。把事务控制在submitOrder这个边界上，任何一个子操作失败，前面所有已执行的SQL都会回滚。这也是答辩时最值得展开讲解的一段代码。

4. 开发环境与实战部署

4.1 环境搭配清单一览

构建SSM项目，环境选择上不要走极端，用一套最兼容、资料最多的组合就够了：

• JDK 8或11，推荐JDK 8，版本兼容性最稳
• Maven 3.6+，用来管理依赖
• Tomcat 8.5或9.0
• MySQL 5.7或8.0，注意8.0的连接驱动和时区配置
• IDEA旗舰版或Eclipse

依赖管理用Maven，在pom.xml里引入spring-context、spring-webmvc、mybatis、mybatis-spring、mysql-connector-java、jackson-databind、jstl、pagehelper等。版本号不用刻意追新，用网上教程里验证过的主流版本就好。我自己见到最多的翻车原因就是spring和mybatis-spring版本不匹配，启动直接报BeanCreationException，这类问题排查起来特别费时间。

4.2 核心配置文件：最容易被忽视的三个点

SSM项目能不能跑起来，全看三个配置文件：Spring的applicationContext.xml、SpringMVC的spring-mvc.xml、MyBatis的mybatis-config.xml。

Spring配置文件主要负责扫描Service和Dao层的组件，配置数据源，以及把SqlSessionFactoryBean交给Spring管理。数据源用c3p0或者druid都行，个人更推荐druid，因为它自带的监控页面在答辩现场展示的时候挺有视觉冲击力。

SpringMVC配置文件主要负责扫描Controller层、配置内部资源视图解析器、放行静态资源。视图解析器最常用的是InternalResourceViewResolver，前缀/WEB-INF/views/、后缀.jsp。如果页面放在webapp根目录，就不需要前缀了，直接返回逻辑视图名。

MyBatis配置文件最核心的就是驼峰映射和别名：

<settings> <setting name="mapUnderscoreToCamelCase" value="true"/> </settings> <typeAliases> <package name="com.demo.entity"/> </typeAliases>

mapUnderscoreToCamelCase这个开关打开后，数据库里的product_name字段就能自动映射到Java里的productName属性，不用你手动写一大堆resultMap。这个细节很多人不知道，导致查询结果为null还查不出原因。

4.3 建库脚本：直接可以用的一版核心表结构

下面是商店管理系统最核心的几张表的简单建表SQL，字段约束已经做了精简，可以在此基础上扩展：

CREATE TABLE t_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, real_name VARCHAR(20), role TINYINT DEFAULT 1 COMMENT '0管理员,1收银员', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE t_category ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, sort INT DEFAULT 0 ); CREATE TABLE t_product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, category_id BIGINT NOT NULL, product_name VARCHAR(100) NOT NULL, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, status TINYINT DEFAULT 1 COMMENT '1上架,0下架', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE t_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2), status TINYINT DEFAULT 0 COMMENT '0待支付,1已支付,2已发货,3已完成,4已取消', receiver_name VARCHAR(20), receiver_phone VARCHAR(20), receiver_address VARCHAR(200), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE t_order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, product_id BIGINT NOT NULL, product_name VARCHAR(100), price DECIMAL(10,2), quantity INT NOT NULL e);

建表之后别忘了插入一条初始管理员账号，比如username=admin、password为加密后的值，不然系统启动后你连登录页面都进不去，这种事是真的会发生的。

4.4 单表分页：一句插件调用搞定

分页查询最省事的方式是集成PageHelper插件。在MyBatis配置里注册插件后，写查询只需要两行代码：

PageHelper.startPage(pageNum, pageSize); List<Product> list = productMapper.pageQuery(product); PageInfo<Product> pageInfo = new PageInfo<>(list);

PageHelper会自动拦截下一条查询SQL并拼接LIMIT语句，PageInfo里封装了总记录数、总页数、当前页、是否有上一页下一页等分页信息。传给前端就能直接渲染分页条。

实测下来PageHelper有个需要留意的地方：startPage只对紧随其后的第一条查询生效。如果你在startPage和查询之间又执行了其他查询，分页就会作用到错误的SQL上，导致数据总数不对。所以pageNum和pageSize的获取、startPage的调用和Mapper查询这三行必须紧挨着写。

5. 论文写作与答辩准备

5.1 论文目录结构：按软件工程标准套路走

论文框架基本是固定的，按软件工程的两大标准流程套就行：

• 摘要和关键词
• 第一章 绪论（背景与意义、国内外现状、研究内容）
• 第二章 相关技术介绍（SSM框架、MySQL、前端技术）
• 第三章 系统分析（可行性分析、需求分析、用例图、业务流程）
• 第四章 系统设计（架构设计、功能模块设计、数据库设计）
• 第五章 系统实现（重点模块的页面截图和核心代码）
• 第六章 系统测试（测试环境、功能测试用例表、测试结果）
• 总结与展望
• 参考文献

字数控制上，第二章这种纯技术介绍不要写太长，因为查重会查得很难看。真正要下功夫的是第三章的需求分析和第四章的数据库设计，这两章是评委老师会仔细看的部分。数据库设计章节把每一张表的字段清单、字段类型、约束说明、表之间的关系讲清楚，再配上ER图，至少能拿一半的篇幅。

5.2 图表三件套：系统架构图、业务流程图、ER图

论文要想显得专业，图比文字更能加分。这里有三张图是核心标配：

系统架构图，画清楚展示层、控制层、业务层、持久层和数据层之间的关系，各层用什么技术一目了然。业务流程图，至少要画采购入库流程或订单处理流程，用标准的方框和箭头图式表达。ER图，将核心数据表及实体关系可视化，注意标注一对多和多对多的关系。

画图工具不挑贵的，开源工具或者在线绘图工具都行，核心要求是风格统一、线条干净、字体一致，不要一张图一个样式。答辩现场，老师看你的论文结构是否完整，先看的就是图和表。

5.3 测试章节：别只写“功能正常”

软件测试章节是很多人蒙混过关的地方。光写“登录功能正常，商品管理功能正常”没有任何说服力。规范的写法是表格化测试用例：用例编号、测试模块、测试步骤、预期结果、实际结果，最后加一列是否通过。

比如登录模块可以拆出5条用例：正确账号密码登录、密码错误登录、用户名不存在登录、空表单提交、连续登录失败次数限制。每条都按标准格式写清楚，这个章节看起来就是实打实做过的。性能测试简单带过就行，比如用并发工具模拟50个用户同时访问首页，平均响应时间在某个数值以内，主要体现你有测试意识。

5.4 答辩前的几个必答题准备

答辩的时候，老师最爱问的问题是固定方向的，提前准备就能稳住场：

• 项目用的什么架构？为什么选SSM？这个问题要讲出框架的分工和优缺点。
• 数据库表之间是什么关系？准备好拿订单表和订单明细表来举例。
• 订单模块怎么保证一致性？直接引到@Transactional事务回滚机制，讲清楚“先插主表再插明细再扣库存”的流程。
• 如果用户量变大了，性能瓶颈在哪里，怎么优化？答加缓存、加索引、数据库读写分离，哪怕没做过也要能说出来思路。

预先准备几个题目的回答思路，比临时翻源码强一百倍。关键是不要背整段话，只记住每个问题的一两个核心关键词，现场用自己的话讲出来反而更自然。

6. 常见问题与排查技巧实录

6.1 启动时报数据库连接失败

这个问题的出现频率我自己认为能排到前三。如果你是MySQL 8.x的驱动，URL里必须加上时区配置，比如jdbc:mysql://localhost:3306/shop?useSSL=false&serverTimezone=Asia/Shanghai，否则启动会报CLIENT_PLUGIN_AUTHENTICATION或者时区相关的异常。另外检查连接用户名和密码是否有权限访问目标库，很多人习惯用root跑项目，一旦密码不是root默认值就会出现连接拒绝。建议建一个专用账号，只授权操作shop这一个库，既安全又能避免权限过大导致的连锁问题。

6.2 页面中文数据出现乱码

中文乱码几乎人人都会遇到，通常是编码不一致导致的。数据库表用utf8mb4字符集，页面JSP声明UTF-8，连接URL加上characterEncoding=utf8，还要在web.xml里配置Spring提供的CharacterEncodingFilter，强制请求和响应都走UTF-8。只要这四层都统一了，乱码问题基本不会出现。

<filter> <filter-name>encodingFilter</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

6.3 查询结果全都是null

Mapper查询正常，SQL也正常执行了，但返回的对象属性是null。八成是数据库下划线字段名和Java驼峰属性名没有对应上，而mybatis-config.xml里又没有打开驼峰映射开关。解决办法就是补上mapUnderscoreToCamelCase=true配置，或者把查询语句里的字段显式起别名，让它和实体属性名保持一致。

6.4 页面找不到或样式丢失

出现404页面找不到，先确认项目部署路径和视图解析器配置是否正确，还有Controller里的请求路径和页面文件的实际位置是否对得上。样式全丢通常是静态资源被拦截了，SpringMVC会拦截所有请求，默认情况下js、css、图片这些静态资源也会被当成普通请求处理。需要在spring-mvc.xml里配置静态资源放行：

<mvc:resources location="/static/" mapping="/static/**"/>

6.5 分页数据不对，总数对不上

PageHelper分页后总记录数不对，绝大多数情况是startPage之后又多执行了一条查询，分页SQL作用到了错误的Mapper方法上。还有可能是统计总数时使用了select * from t_product，PageHelper自动生成的count语句忽略了条件，导致总数恒为全表数量。排查思路很简单：启动项目打日志，看SQL输出抓出来的实际查询语句是哪条，定位到之后把startPage和业务查询紧挨着放，中间不要插入任何无关数据库操作。

6.6 事务回滚不生效的三种情况

如果你确认加了@Transactional但数据还是写进去了，从三个方向排查。一是注解作用的类是否被Spring容器管理，如果是new出来的对象，事务代理自然不生效。二是方法是否是非public，非public方法无法被代理。三是SpringBoot的自动配置默认是CGLIB代理，但在传统SSM手写配置里，如果用到SpringAOP且没有开启注解驱动，@Transactional也可能形同虚设。在配置文件里添加<tx:annotation-driven/>是最稳的保障。

6.7 修改代码后不生效

这个问题排查起来很容易让人心态爆炸。改完JSP页面刷新还是老样子，优先强刷浏览器清缓存。改了Java代码重启Tomcat后没变化，八成是IDEA没有重新编译，执行Build Rebuild Project。改了配置文件没生效，多半是Tomcat没有把旧的部署目录清理干净，clean一下再重新部署基本就能解决。

一点个人体会

我见过不少同学拿到一套源码之后，第一反应是赶紧跑起来截图，然后照着论文模板开始抄。系统可能跑起来了，但问他订单状态为什么这么设计，库存扣减失败会不会回滚，他就说不清楚了。倒不是说毕设一定要研究得多深，但起码你得对自己交付的东西负责。我的建议是不管你从哪里拿到的项目，拿到之后第一件事不是部署，而是把数据库表关系画出来，把代码从Controller到Service到Mapper的调用链走一遍。这个过程花费的时间不会太多，但效果比答辩前熬夜背源码好得多。

最后再分享一个小经验：把你系统演示的过程用录屏工具记录下来，带着录好的视频去答辩。在线演示最怕网络卡顿、数据库没启动、浏览器缓存异常这些突发事件，一份提前录好的、操作流畅的演示视频能兜底。视频录完还可以放在作品展示页面里附上，也算是一种成果包装。整个项目从运行、讲解到论文成稿，都会顺很多。