企业官网建设流程全解析

1. 项目整体拆解：校园消费点评到底做了什么

1.1 核心需求定位

校园消费点评系统，说白了就是给校内食堂、商铺、水吧这些消费点位做一个类似大众点评的轻量化平台。很多高校的餐饮档口动辄几十个，哪个窗口好吃、哪家店排队久、哪个菜品踩过雷，过去全靠同学之间口头传播，信息零散且容易失真。我接手这个项目的时候，某高校后勤的老师就提了两个硬需求：一是让学生能快速查到附近窗口的真实口碑，二是后勤管理部门能通过数据知道哪些档口评分差、投诉多，到期好决定续约还是清退。

这个系统本质上是一个垂直领域的CRUD项目，但难点不在增删改查，而在“点评”这个动作背后的业务逻辑——评分怎么设计才不虚高？匿名点评怎么防恶意刷评？窗口换了承包商之后历史点评要不要清空？这些问题如果不在设计阶段想清楚，后面写代码全是坑。整个项目拆下来，最核心的价值就是把“人—店—点评—数据统计”这条链路打通，让学生评价有出口、商家经营有反馈、管理方决策有依据。

1.2 功能模块与角色权限设计

系统分了三种角色：学生用户、商家（档口管理员）、系统管理员。学生用户能做的就是登录、浏览店铺、发点评、收藏喜欢的窗口、查看自己的点评记录；商家能维护自家店铺信息、回复点评、查看被投诉的记录；管理员的权限最大，负责审核点评内容、管理店铺入驻、屏蔽违规用户、查看全校消费点评的数据报表。

权限设计上我建议直接用Spring Boot的拦截器配合注解搞定，没必要上Spring Security那套重家伙。定义好@RequireRole注解，在Interceptor里判断当前登录用户的角色，匹配不上就直接拦截跳转。这个做法对单体应用来说足够干净，而且代码量少、容易调试。后台管理界面和前台展示页面共用一套登录态，用一个user_type字段区分角色，不要为了区分角色去建多个用户表。

1.3 技术选型背后的取舍逻辑

技术栈这块我最终定的组合是：Java 8 + Spring Boot 2.7.x + MyBatis Plus + MySQL 5.7 + Thymeleaf + Bootstrap + Layui。没有用前后端分离，也没有引入Redis和消息队列，原因很简单——这个项目的信息量级和并发量压根不需要那些中间件，堆技术栈只会增加部署和调试成本。Spring Boot的选择没什么争议，它把配置自动化做到了极致，内嵌Tomcat让部署只需要一个jar包，这对学校机房那种不太规范的服务器环境反而是最友好的。

MyBatis Plus比原生MyBatis省事的地方在于单表CRUD基本不用写XML，分页插件也现成。不过要注意，MP的自动填充字段和逻辑删除功能虽然方便，但如果你要在点评统计中用count(*)，逻辑删除的全局配置会影响所有SQL，必须在应用层注意这些规则对统计结果的影响。后面我在第四节会讲这个坑的具体表现。

2. 数据库设计与关键表结构

2.1 整体表结构规划

数据库我设计了六张核心表：用户表、店铺表、点评表、店铺分类表、收藏表、管理员操作日志表。用户表没什么特殊，手机号做登录账号，密码用BCrypt加密存储；店铺表最关键的是owner_id字段，用来关联商家用户ID，这样商家登录后只能维护自己的店铺数据。

店铺分类表很有意思。校园场景里食堂窗口经常调整，一间铺位这学期卖麻辣烫下学期可能改卖螺蛳粉，所以分类不能只挂在店上，而是建议单独建一张分类表，店铺表里存分类ID。这样换品类时只需要改一个关联字段，不会动到业务表。点评表是整个系统设计的重点，我单独用一节详细说。

2.2 点评表与评分字段的设计细节

点评表的字段看起来简单——用户ID、店铺ID、评分、内容、图片——但评分这里我踩过坑。最早图省事只设计了一个score字段，后来接手需求才发现后勤老师要看的是“口味、服务、卫生、性价比”分维度评分，单字段根本满足不了。最后拆成了taste_score、service_score、hygiene_score、price_score四个字段，总分由这四个的均值算出来，存的时候也把avg_score冗余进去，方便直接排序。

店铺表里也冗余了三个统计字段：total_rating_count、total_score_sum、avg_rating。每次新点评提交，就在事务里同步更新这三个字段。这样做的好处是店铺列表页直接按avg_rating排序就能出来口碑排行，不需要实时join点评表做聚合，大数据量下的查询性能完全撑得住。

点评状态用枚举值管理，0待审核、1已发布、2已驳回、3已删除。为什么要有待审核状态？因为管理员无法保证每个点评都真实可信，有些评价可能涉及辱骂或者广告，必须有人工审核的兜底机制。这里我也做了个小优化：老用户在系统里信用分高，发点评直接跳到已发布；新注册用户前三条点评全部走审核流程，能有效过滤大部分垃圾内容。

3. 核心功能实操实现

3.1 登录鉴权与用户体系

登录这块用的是Session方案，登录成功后把user_id和user_type写进Session，每次请求通过拦截器统一校验。为什么不用JWT？因为这是一个多页面服务端渲染项目，Thymeleaf页面在服务端直接渲染用户信息，JWT的优势在单体服务端渲染架构中完全发挥不出来，反而要处理token过期刷新、前端存储安全这些问题，徒增复杂度。

密码安全这块提个醒：千万不能用MD5直接存，一定要用BCrypt。Spring Security里自带了BCryptPasswordEncoder，即使不引入完整的Security框架也可以单独把这个工具类拿出来用。BCrypt的校验逻辑会把盐和哈希存在同一个字符串里，校验时自动从密文里解析盐值，不需要额外字段存盐，实现起来非常省心。

注册流程里还做了一个贴心的功能：校园邮箱验证。考虑到同学可能注册完忘记密码，系统绑定了学校的邮箱，支持找回密码。实现方式就是发一封包含重置链接的邮件，链接带一个随机token，有效期30分钟。这个功能代码不多，但对用户体验的提升非常明显。

3.2 点评发布与关联店铺

点评发布是整个系统里事务最多的操作——插入点评记录、更新店铺统计、维护用户点评数、清理缓存。我把这些操作全部放进@Transactional注解的方法里，任何一步失败都会整体回滚，避免出现点评写成功了但店铺评分没更新的脏数据。

发布点评时有个很实用的校验逻辑：同一个用户对同一家店铺只能有一条有效点评。在comment表上建了用户ID和店铺ID的联合唯一索引，效果是防止重复点评。但后续需求变了——用户要能修改自己的点评，不是删了重发，而是要编辑。这时候联合唯一索引就会挡路，因为修改时要把原记录状态改成删除，再插入新记录，两条记录会同时存在。

我最后用的方案是：状态字段不参与唯一约束，在应用层通过查询判断该用户是否已对该店铺发表过有效点评，如果有就跳到编辑页而不是发表页。联合唯一索引这种做法对于“一条记录只能存在一次”的场景是终极防线，但一旦涉及更新历史记录，就不得不让路给业务逻辑。这种取舍要根据实际情况动态调整。

还有一个不能忽视的点：图片上传。点评图片我用的是本地磁盘存储方案，不是数据库存base64也不是OSS。在服务器的配置目录下建一个upload/comment文件夹，文件名用UUID重命名，路径存到数据库。好处是部署简单、不依赖外部存储服务，坏处是配置的路径不对时在Linux上容易PermissionDenied，这个坑我在后面排查实录里会细说。

3.3 检索与排行接口

店铺列表页支持按分类筛选、按评分排序、按销量排序，这里其实就是一个动态条件查询。用MyBatis Plus的LambdaQueryWrapper，根据前端传过来的category_id、sort_type、keyword参数动态拼条件，避免了XML里写一堆<if>标签的条件判断。

排行接口算是这个系统的一个亮点：统计每个店铺的评分均值、点评数量，生成“食堂口碑榜”和“热门窗口榜”。SQL里用一个子查询先把店铺ID、点评数、均分算出来，再关联店铺表取出详情。关键是均分保留两位小数，不然会出现一堆0.999999的问题。后端用MySQL的ROUND函数处理，比在Java代码里处理更简单有效。

对于分页查询，我用的MP分页插件拦截器自动拼接limit语句。要特别提醒的是：一定要配置分页拦截器，不配置的话Page对象传进去只是参数绑定，并不会真正分页，返回结果还是全部数据。这个是最常见的低级错误之一。

4. 前后端交互与页面组织

4.1 页面层级与服务端渲染

页面布局模板我抽取了一个公共的header和footer片段，用Thymeleaf的th:replace语法在每页引入。导航栏里根据用户角色动态渲染菜单——普通用户显示“我要点评”“我的收藏”，商家显示“店铺管理”“回复管理”，管理员显示“审核中心”“数据报表”。这块不涉及复杂的前端框架，把公共片段抽好之后，每页的开发成本大幅下降。

前端的核心逻辑其实在店铺详情页。页面左侧是店铺基本信息、地址、营业时间、公告；右侧是点评列表，每条点评显示用户昵称、发评时间、分维度评分条和点评内容。评分条我用CSS星级样式实现——输入的是数值，前端通过遍历输出实心星和空星，不需要任何图表库，几行th:each就能搞定。

表单校验我采用了前端JS校验加后端校验双层方案。前端校验快速响应用户操作，比如点评内容不能为空、评分不能为零；后端校验才是真正的安全防线，因为正则表达式校验可以轻松被绕过，后端必须再做一次字段验证。我在后端用Hibernate Validator注解，在实体上直接加@NotBlank和@Max这些约束。注意分页参数异常的问题也要处理：页码必须大于0，如果传1000000，在大的分页量下数据库查询会很吃力。

4.2 商家管理后台与管理员审核后台

商家管理后台的页面设计逻辑是：登录后先看到本店的评分趋势和数据概览，下方是点评列表，每条点评旁边有“回复”按钮。回复功能做成了商家和用户之间一对一的对话流，同一个点评下的回复按时间顺序排列，商家只能回复一次，避免双方陷入无限互怼。

管理员审核后台是一个待办列表，展示所有待审核的点评，管理员可以查看原文、图片，然后选择“通过”或“驳回”。驳回时必须填写原因，系统会通过站内信把这个原因通知给发布者，让用户知道为什么评价没通过。这个功能做出来之后，同学的满意度提升非常明显——之前都是默默被删，现在至少知道是哪里不合规。

管理员数据报表我做成了四个页签：点评数量趋势、店铺评分分布、活跃用户排行、分类消费占比。由于没有引入ECharts，我最初用表格展示，效果很一般；后来引入一个轻量图表库，数据由后端接口返回JSON格式，前端绘图，视觉效果好多了。如果不想引入重量级图表库，用CSS画简单柱状图也是个可行的替代方案。

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

5.1 并发点评时的数据一致性问题

系统上线之后遇到一个比较典型的并发问题：宿舍室友同时发点评，店铺的total_rating_count和total_score_sum会出现偶发性的对不上。原因分析清楚了——两个事务并发读取店铺统计字段的值，各自加了新的评分后写回，后写的覆盖了先写的更新，导致少加了一次。

解决方案是改用原子更新SQL：UPDATE shop SET total_score_sum = total_score_sum + #{score}, total_rating_count = total_rating_count + 1 WHERE id = #{shopId}。这样数据库行锁保证并发安全，不会出现读到旧值的问题。这个问题的本质是典型的读改写竞态，排查时用了日志跟踪事务执行时间，发现两次更新间隔极短，顺藤摸瓜找到了根因。

5.2 点评图片上传失败的排查记录

上线后收到反馈说点评图片传不上，查看日志发现报FileUploadException，提示的是临时目录权限不足。问题出在Linux服务器上/tmp分区被系统清理，而Tomcat默认的上传临时目录就在/tmp下。这个报错不是每次都出现，而是系统清理临时文件后才会触发，非常难排查。

解决办法是在配置文件中显式指定上传临时目录到项目自定义目录，并且该目录要加入开机自动创建的脚本里。另外还发现一个问题：上传图片后前端预览时用的是本地相对路径，但在列表页重新渲染时图片路径拼接错误，导致部分图片显示不了。最后统一用File.separator拼接路径，保证Linux环境的斜杠方向正确。

5.3 服务端渲染页面中文乱码问题

这个问题在前后端分离架构里几乎不会出现，但服务端渲染场景很容易踩：Thymeleaf模板文件没有设置为UTF-8编码，结果页面上的中文全部显示成问号。排查时查看浏览器开发者工具发现响应头里Content-Type没有带charset=UTF-8，确认是模板文件编码设置的问题。

在application.yml里配置spring.thymeleaf.encoding: UTF-8并保证模板文件本身是以UTF-8保存的，乱码问题彻底解决。另外还有一个容易被忽略的坑：页面里的<meta charset="UTF-8">必须放在<head>最前面，否则浏览器在解析到meta标签之前可能已经用默认编码渲染了一些字符。

5.4 接口返回时间过长的排查思路

有一个阶段店铺搜索页响应特别慢，平均耗时在2秒以上。我先用慢SQL日志查数据库，发现有一个查询没有走索引——店铺表按照名称做模糊搜索时LIKE '%关键词%'导致全表扫描，数据量只有几百条时感觉不到问题，但到几千条时就已经明显卡顿。

优化方案是拆成前缀匹配搜索：LIKE '关键词%'配合MySQL前缀索引，能把查询时间从900ms降到50ms左右。更彻底的办法是引入全文索引或者ES，但对于校园场景的项目规模完全没有必要——应用层做关键词分词，缓存最近搜索结果，响应速度就已经完全够用。

6. 部署配置与上线注意事项

6.1 生产环境的配置管理

这个项目我采用Jar包部署方案，配合Systemd服务管理。配置上把环境相关的参数全部抽离到application-prod.yml，开发环境和生产环境通过启动参数--spring.profiles.active=prod切换。数据库连接、上传路径、邮件服务器这些敏感配置不能写死在代码仓库里，生产环境用环境变量覆盖。

另外，服务端渲染项目一定要配置Tomcat的虚拟路径映射，把上传目录映射成一个/upload/**的访问路径，否则前端页面无法通过URL访问上传的图片。配置方法是在Spring Boot里重写WebMvcConfigurer中的addResourceHandlers方法。

6.2 数据备份与日常维护

数据备份我用的是MySQL自带mysqldump工具，学校机房的服务器硬盘不大，所以每天凌晨做一次全量备份，保留最近七天。备份脚本里做了压缩，一条命令搞定：

mysqldump -u用户名 -p密码 数据库名 | gzip > /backup/school_review_$(date +%Y%m%d).sql.gz

恢复的时候注意，如果备份文件里有DROP TABLE IF EXISTS语句，执行前一定再确认操作环境，别把最新的数据覆盖了。这个脚本我一开始没加保留天数的清理逻辑，结果连续跑了两个月，磁盘差点被备份文件撑爆。教训就是定时任务的日志和备份文件清理策略一定要在第一天就做好。

运营层面也有一条要提醒：校园消费点评系统最大的数据风险不是宕机，而是商家更替。每个学期都有窗口退租，店铺表中的历史点评如果直接清空，整个系统的公信力就下降了。我们的做法是店铺下线时把状态改为停止营业，历史点评全部保留，新入驻的商家重新建店，这样既尊重历史数据，也方便学生区分新旧商家——毕竟一家店换老板前后的口味可能天差地别。

7. 写在使用后面：一些真实的复盘与建议

整个项目从需求梳理到上线运行，前后花了大概两个月时间。我个人最大的体会是：这类校园垂直场景的小型系统，技术难点从来不在框架使用上，而在业务细节的打磨。比如评分维度怎么拆、审核流程怎么走、商家换人后历史数据怎么处理——这些需求不经走访调研是根本设计不出来的。如果你正在做毕业设计或者接类似的外包项目，建议花更多时间在需求沟通和数据模型设计上，把业务规则想透了再动手写代码。

最后分享一个小技巧：在开发阶段我就用Docker把MySQL和Redis的环境固定下来，避免团队成员各自电脑的数据库版本不一致导致反复踩坑。这个习惯后来在部署时也帮了大忙——生产环境的MySQL版本和本地完全一致，几乎没有出现环境差异导致的问题。项目的git提交记录里，每次业务变更我都习惯连带着把数据库变更脚本一起提交，这样一旦需要重建测试环境，一条命令就能把表结构和初始数据全部拉起来。