企业官网建设流程全解析

1. 整体架构设计：为什么选SpringBoot+SSM这套组合？

做在线招标系统这类项目，大多数人第一个纠结的点不是功能怎么做，而是技术栈怎么选。市场上五花八门的方案太多，SpringCloud微服务太重、PHP写起来快但面试拿出来不够看、Python的Django在国内企业落地反而少——综合下来，Java系里的SpringBoot+SSM几乎是最稳的选择，没有之一。

先说SpringBoot和SSM的关系。很多人把这两个概念混在一起，其实它们不是同一个层面的东西。SSM是Spring+SpringMVC+MyBatis三个框架的合称，负责把项目拆成控制层、业务层、持久层来做；而SpringBoot是另一个角度的解决方案，它把Spring家族里那些繁琐的XML配置、依赖管理、部署流程全部做了自动封装。用SpringBoot整合SSM，本质上是让原本需要几十行配置文件才能跑起来的SSM项目，压缩成几个注解就搞定，同时保留SSM的分层思想和MyBatis的SQL可控性。

我当时选这套组合，核心考量有三个：

第一，招聘市场的匹配度。国内绝大多数中小型企业的Java岗位，日常工作就是维护这类单体业务系统，SpringBoot+SSM是出现频率最高的组合。做完这个项目，简历上写的技术栈和面试官问的东西能对得上。

第二，开发效率与学习成本的平衡。如果直接上SpringCloud全家桶，光理解服务注册、配置中心、网关这些概念就要花两周，而在线招标系统的业务复杂度完全用不到微服务。反过来，如果只用原生的SSM而不引入SpringBoot，那些XML配置就够让人头疼的。SpringBoot的自动配置特性，让我把精力集中在招标、投标、开标、评标这些核心业务逻辑上。

第三，部署运维简单直接。毕业设计或者个人项目最终要跑给老师、面试官看，SpringBoot内嵌的Tomcat让打包变成"一个jar包扔上去就能跑"，不用再单独装Tomcat、配环境变量，演示的时候特别省心。

这套组合的技术分工大概是这样的：

这种选型最大的好处是整个项目一个人从头写到尾不费劲。一个"单体应用+模板渲染"的项目，在代码量、可理解性、演示效果之间取得了一个很舒服的平衡点。你要是用Vue前后端分离，就得维护两套工程，写跨域配置，调试接口，工作量直接翻倍。而服务端渲染的Thymeleaf把页面和Controller绑在一起，流程在代码里顺着就能读下来。

提示：如果你是一个刚接触这类系统的人，架构上不要贪多。招标系统的核心价值在业务规则的严密性——谁在什么时间能干什么事——而不是技术架构有多花哨。

2. 核心功能模块与数据库设计拆解

在线招标系统的业务闭环可以从两条线来理解：一条是招标方的发标线，另一条是投标方的参与线，中间用"开标"和"评标"两个节点咬合起来。一个完整可演示的项目，功能模块至少要覆盖下面这张图的内容。

2.1 用户角色与权限设计

系统里的用户粗分四类：管理员、招标方（采购人）、投标方（供应商）、评标专家。在Spring Security的体系里，我给每类角色分配了不同的访问端点。比如/tenderer/**只有招标方角色能访问，/bidder/**只有投标方角色能访问，而/expert/**则限定评标专家。这种URL粒度的权限控制实现起来不复杂，但在答辩和演示时非常加分，因为评审老师很关心"投标方能不能绕过权限去操作招标方的接口"这类越权问题。

JWT做登录态管理是个实用选择。用户登录成功后，后端签发一个带角色信息的token，前端存在本地，每次请求放进请求头里。Spring Security过滤器链里做的验证逻辑大致是：先从请求头取token，解析出用户ID和角色，再比对当前请求路径需要的权限，有权限就放行，没有就返回403。注意token里不要放敏感信息，签名密钥要用足够长的随机字符串。

2.2 功能清单速览

• 系统管理模块：用户管理、角色管理、菜单权限、操作日志
• 招标项目管理：招标公告发布、招标文件上传、项目状态流转（待审核→报名中→开标中→评标中→已完成）
• 投标管理模块：在线报名、标书上传、标书撤回、保证金记录
• 开标与评标模块：开标时间提醒、评标评分表、综合评分计算、中标候选人排序
• 信息公示模块：中标公告发布、历史项目查询
• 消息通知模块：站内信、关键节点邮件提醒

2.3 数据库表设计思路

数据库表是整个系统里最需要仔细打磨的部分，它直接决定了业务逻辑能不能严谨落地。我把核心表分成三组：

用户与权限组：sys_user（用户表）、sys_role（角色表）、sys_user_role（用户-角色关联表）。关联表的存在是为了保留扩展空间，虽然目前角色只有四个，但之后想加一个"监督员"角色，不需要改表结构。

招标业务组：tender_project（招标项目主表）、tender_file（招标文件表，存放文件路径和上传时间）、bid_record（投标记录表）、bid_file（投标文件表）。

评标结果组：bid_evaluation（专家评分表）、tender_result（中标结果表）。

以tender_project表为例，字段设计时要注意几个容易忽略的地方：

1. 项目状态字段用int不用varchar。虽然"报名中""已截止"这种字符串看文档很直观，但代码里到处写中文比较判断很容易出错。用status字段存0/1/2/3/4，枚举含义放在Java常量类或枚举里统一管理，代码整洁度会高很多。

2. 金额字段用decimal不用double。保证金、预算金额这种跟钱沾边的数据，float/double会有精度丢失问题，老手基本不会踩，但新手很容易忽略。decimal(12,2)可以覆盖百万级的金额，精度够用。

3. 所有表保留create_time和update_time。这看起来像废话，但很多初学项目确实会漏掉。留着这两个字段，出问题排查数据变更时间线会省很多力气。MySQL这边可以用DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP自动维护，不占用业务代码成本。

4. 关联业务表加冗余的project_name字段。比如bid_record表除了project_id外，冗余一个project_name。虽然违反了严格意义上的第三范式，但在列表页展示时能少写好几条关联查询，对查询性能也有帮助。

具体建表SQL我贴在下面，这是tender_project表的精简版本，你可以参考：

CREATE TABLE `tender_project` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `project_code` varchar(32) DEFAULT NULL COMMENT '项目编号', `project_name` varchar(128) NOT NULL COMMENT '项目名称', `budget_amount` decimal(12,2) DEFAULT NULL COMMENT '预算金额', `status` tinyint(4) DEFAULT 0 COMMENT '状态:0草稿,1待审核,2报名中,3开标中,4评标中,5已完成,6已终止', `publish_time` datetime DEFAULT NULL COMMENT '发布时间', `bid_deadline` datetime DEFAULT NULL COMMENT '投标截止时间', `open_time` datetime DEFAULT NULL COMMENT '开标时间', `create_by` bigint(20) DEFAULT NULL COMMENT '创建人ID', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_status` (`status`), KEY `idx_bid_deadline` (`bid_deadline`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='招标项目表';

索引方面，我会在status和bid_deadline上建索引，因为列表页最常见的就是按状态过滤、按截止时间排序。很多人做项目不建索引，数据量小的时候没事，但演示时如果造了上千条测试数据，索引的差距立刻体现出来。

2.4 关键业务逻辑的点位

招标流程的校验。发布招标项目时，需要校验投标截止时间必须晚于发布时间至少72小时之类的规则。这类校验不能只写在页面上，Controller里必须再校验一次，否则有人绕过前端直接POST接口就乱套了。

投标截止的不可逆性。系统需要在投标截止时刻做状态翻转。最简单的做法是在查询时实时判断bid_deadline < now()就按已截止处理，不一定要依赖定时任务去更新状态。如果非要自动改状态，用Spring的@Scheduled注解写一个定时任务，每5分钟扫一次status=2且bid_deadline < now()的项目，把状态改成3。两种方案我建议都做：查询时实时判空保证逻辑正确，定时任务做兜底让数据状态更好看。

评标分数的计算。每个专家给投标方打分后，最终得分建议采用"去掉一个最高分、去掉一个最低分、取平均"的规则。这个逻辑在Service层用Java实现比较容易，对评分表做排序后剔除首尾再取平均即可。

3. 实操过程：从搭建环境到跑通第一笔业务

这部分我把实际动手的过程完整走一遍。假设你现在拿到的是一份别人写好的源码，你想把它跑起来看效果，或者自己从头搭一个骨架，下面的步骤都能对得上。

3.1 环境准备与版本匹配

这个项目推荐的版本组合是：

• JDK 1.8（注意不要用太高版本，比如JDK 17，部分老版本的MyBatis或者Spring会有兼容问题）
• Maven 3.6+
• MySQL 5.7（8.0也可以，但注意驱动类和连接串差异）
• IDEA（社区版就够用，不需要旗舰版特有的Spring功能）

这里要特别提醒一个版本陷阱：SpringBoot的版本要和MyBatis Starter的版本匹配。我见过很多人直接把SpringBoot升到2.7甚至3.x，然后MyBatis的starter还停留在1.x，启动直接报ClassNotFoundException。推荐组合是SpringBoot 2.3.x + mybatis-spring-boot-starter 2.1.x，这个组合在网络上能找到最充分的踩坑资料。

Maven的pom.xml里核心依赖大致如下：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.3.12.RELEASE</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.1.4</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.49</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> <dependency> <groupId>org.thymeleaf.extras</groupId> <artifactId>thymeleaf-extras-springsecurity5</artifactId> </dependency> </dependencies>

3.2 初始化数据库与配置文件

拿到源码后第一步不是急着启动，而是先把数据库准备好。在MySQL里创建一个tender_system库，然后把项目里的sql目录下的建表脚本按顺序执行。如果脚本里带了初始数据（管理员账号、演示数据），一起导入，后面调试会省很多事。导入完成后，用Navicat或者命令行连上去，随便查两张表确认数据是真的进去了。

然后打开application.yml，重点看这几处配置：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/tender_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.jdbc.Driver thymeleaf: cache: false mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.tender.entity configuration: map-underscore-to-camel-case: true

map-underscore-to-camel-case这行配置很关键，开启后数据库里的create_time能自动映射到Java实体里的createTime，不用在Mapper.xml里写一堆resultMap。很多报错都是因为没开这个开关，导致查出来的字段全是null。

3.3 启动项目与初始化账号

执行mvn spring-boot:run，或者在IDEA里直接运行主类。看到类似Tomcat started on port(s): 8080的日志就说明启动成功了。

访问http://localhost:8080/login，使用初始化脚本里预设的账号登录。通常会有一个超级管理员账号，用它可以查看全部功能、创建其他角色用户。这里建议你演示之前先创建好招标方、投标方、评标专家三个账号，然后用不同浏览器的隐身窗口分别登录，模拟完整的"发标→投标→开标→评标→定标"流程。

3.4 功能链路自测清单

项目跑起来之后，花半小时走一遍核心链路，确认没有明显问题：

1. 管理员登录，创建一个招标方用户
2. 用招标方账号登录，发布一个招标项目，上传一份招标文件（PDF格式，大小别超过配置的上限）
3. 切换浏览器隐身窗口，用投标方账号登录，找到这个项目，在线报名并上传投标文件
4. 回到招标方账号，在项目列表中看到已报名记录
5. 把系统时间对应的bid_deadline设置成过去（或者直接在数据库里改一下状态），触发开标
6. 用评标专家账号登录，对投标方进行评分
7. 回到管理员或者招标方账号，查看综合评分结果和中标公告

这一步走顺了，系统的生产力和可信度就完全立住了。很多演示翻车都是因为在开标环节卡住了——仔细检查一下bid_deadline这个字段的时区问题，服务器时区和大数据库时区不一致会导致截止时间差8个小时。

注意：文件上传大小默认是1MB，演示时上传大文件会报错。记得在配置文件里把spring.servlet.multipart.max-file-size和max-request-size调大到比如10MB/20MB，否则现场演示传个几MB的标书就尴尬了。

4. 常见问题与排查实录

做这个项目的过程中，我整理了一些高频问题，可以说每一个都是真实踩过的坑。按出现频率排序，下面这几个最有代表性。

4.1 Maven依赖下载慢或引入失败

国内网络访问Maven中央仓库的速度问题很多人都体会过。解决方案有两个：

一是配置阿里云镜像。在settings.xml里加一段mirror配置即可：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

二是手动把下载不下来的jar包放进本地仓库。比如某些特殊依赖在中央仓库被下架了，可以用mvn install:install-file命令手动安装到本地仓库。这个办法虽然笨，但确实能救命。

4.2 启动报错"Consider defining a bean of type 'xxxMapper'"

这个报错非常典型，原因是MyBatis扫描Mapper接口的路径配置不对。检查三处：启动类上有没有@MapperScan("com.tender.mapper")注解；或者每个Mapper接口上有没有加@Mapper注解；以及application.yml里mybatis.mapper-locations路径是否真能匹配到XML文件。最常见的错误是把classpath:mapper/*.xml写成了classpath*:mapper/*.xml，或者XML文件的目录没建在resources/mapper下。

4.3 前端请求跨域问题

如果你的项目用了前后端分离的方式（前端单独跑在8081端口，后端在8080），就会遇到跨域。SpringBoot里可以写一个配置类全局处理：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

如果用的是服务端渲染（Thymeleaf），不存在跨域问题，一般不用加这个配置。加了反而可能引起CSRF相关的安全限制冲突，所以建议先用最简单的方式跑通再考虑扩展。

4.4 使用Spring Security后静态资源被拦截

没登录的时候访问/css/**、/js/**直接被跳转到登录页，这是Spring Security默认拦截一切请求导致的。需要开白名单：

@Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .antMatchers("/login", "/css/**", "/js/**", "/images/**", "/fonts/**").permitAll() .anyRequest().authenticated(); }

4.5 上传的文件访问不到

文件上传成功后，页面里的下载链接返回404。排查思路：先确认文件实际保存到了哪里（本地磁盘路径），再确认Spring Boot是否映射了静态资源路径。如果是保存在项目外的目录（比如/data/tender_files），需要在配置里加一个资源映射：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/files/**") .addResourceLocations("file:/data/tender_files/"); } }

注意Linux和Windows的路径写法有差异，Windows下要写成file:D:/tender_files/。

4.6 常见问题速查表

5. 项目扩展方向：从毕设到生产级还差哪几步

如果做完这个项目还意犹未尽，或者想把项目再往上提升一个层次，我建议按优先级做下面几个扩展。这些方向能显著拉开项目与其他作业的差距，面试或者演示的时候也有更多可聊的东西。

第一个方向：加入消息通知机制。目前站内信如果还没做，可以用Spring的事件监听机制做一个简单的"招标状态变化→通知相关用户"的逻辑。不一定要上RabbitMQ，项目规模不到那个程度。等业务量真的大了再引入消息队列也不迟，面试聊起来也更有逻辑——"什么时候引入MQ"本身就是值得展开的话题。

第二个方向：文件存储抽象层。目前文件都是存本地磁盘，可以抽象出一个FileStorage接口，本地实现之外再加一个实现，比如封装阿里云OSS。切换存储只需要改一个配置。这种"面向接口设计"的思路，在代码评审里是明显的加分项。

第三个方向：SQL查询优化。列表页的分页如果项目里还在用PageHelper插件，用的过程中注意它在大数据量下偶尔会有性能问题。可以自己用LIMIT #{offset}, #{pageSize}写一个简单分页，同时统计总数用独立的COUNT(*)查询，这样对SQL的理解更深，面试被问到分页原理也不虚。

第四个方向：接口限流与操作审计。在关键接口上做简单的并发控制，比如"同一个投标方对同一个项目只能提交一次标书"，除了数据库唯一索引兜底，Service层加个分布式锁（或本地锁）也是常见的考察点。

我个人在实际调试这个项目时收获最大的，反而不是某一项技术，而是把"完整业务闭环"这件事从头到尾理清楚——从招标公告发出那一刻，到中标通知书生成，一条线上每一步的数据变化、状态流转、用户权限约束都掌握在手里。这种掌控感是背八股文给不了的。

最后再分享一个小技巧：演示之前，把所有演示数据的时间通过SQL一次性改成当前时间，保证演示时点开项目看到的都是"报名中"或"评标中"的热乎状态，而不是一堆"已结束"的过期数据。这个小动作能让整个演示的沉浸感提升好几个档次。