企业官网建设流程全解析

去年接手了一个让我印象很深的小需求：某高校的老师找到我，说每年期末都要收几百份学生作品，作品分散在邮箱、网盘、QQ群里，评委老师们要一个一个打开看，然后在Excel里登记分数，最后还要人工处理最高分、最低分、平均分排名。听起来不算难，但真正把需求拆开之后，我发现这个“在线作品评分网站”要做的事远比想象中多：作品怎么传、怎么展示、评委怎么评分、怎么防止重复评、分数怎么聚合成排名，还要考虑不同身份的人看到的内容不一样。

这个项目最终落地的技术方案是：后端用 Spring Boot（Java），前端用 Vue，数据库用 MySQL，部署阶段用 Nginx 做静态资源服务与反向代理。整套系统既能上传展示作品，也能在线打分并自动生成排行榜，前后端分离开发，整个流程走通之后，确实把老师从Excel里解放出来了。这篇文章把我从需求梳理、技术选型、后端设计、前端交互到联调部署的关键过程和踩坑经验完整记录下来，希望对正在做类似“作品展示 + 评分系统”或“内部评审系统”的朋友有一点参考价值。

1. 重新定义需求：不止是“把Excel搬到网上”

1.1 最初的需求和真正的问题

老师最初给我的需求描述只有一句话：“做一个网站，学生传作品，评委打分，最后出排名。” 但我们在需求沟通会上把使用流程走了一遍之后，发现这里面藏着好几个容易忽略的点。

首先是作品的形态问题。叫“作品”太笼统了——有的是文档，有的是图片，有的是视频，有的是打包的压缩源码。如果只做单一格式的上传，很多学生根本没法提交，所以系统必须兼容所有常见文件类型，同时为图片、视频这类可以在线预览的格式做单独的展示处理。

其次是评分规则不统一。有的评委习惯打百分制，有的习惯打等级分，还有的想给作品写一段评语。我们在设计评分表时，直接把“分制”定成了统一百分制，评语作为可选项，这样后续聚合排名时逻辑最简单。如果某些场景非要等级制，也可以在前端做一次映射，但数据库存的一定是规范化的数值。

再就是身份权限。学生能上传作品、看别人的作品和最终排名，但不能给别人打分；评委老师可以看作品、打分、看已评作品列表，但不能修改已提交的分数；管理员负责审核作品、处理违规、管理用户。这三类角色的数据边界在项目一开始就必须定义清楚，否则后面加权限逻辑会非常痛苦。

1.2 功能拆分与范围控制

梳理完之后，我把项目范围拆成了四个模块，每个模块再往下分具体功能：

这四个模块基本覆盖了老师所有的需求场景。我给老师的承诺是：学生端和评委端的核心流程必须在第一版全部可用，管理员端可以先粗糙一点。因为一个内部系统，管理员就那么几个人，但学生和评委的使用体验决定了这个系统成不成功。

经验就是：这种小中型的内部系统，别一上来就想着做得很全，把“上传作品 -> 评委打分 -> 出排名”这条主链路做通畅，就已经成功了80%。剩下20%是权限、异常和边界情况的处理。

2. 技术选型与项目初始化：为什么是 Spring Boot + Vue

2.1 后端框架选择背后的考虑

后端选 Spring Boot，主要出于三点考虑。

第一，团队技术栈的匹配度。Java + Spring Boot 在高校和中小型公司里仍然是存量最大、参考资料最多的技术栈，无论是后续找人维护，还是学生参与二次开发，门槛都比较低。相比 Node.js 或者 Python 系的框架，Spring Boot 的生态更“标准”，什么人接手都不会觉得陌生。

第二，Spring Boot 对传统业务场景的支持非常完善。文件上传（MultipartFile）、数据校验（Validation）、权限控制（Spring Security + JWT）、数据访问（Spring Data JPA 或 MyBatis-Plus）都有成熟方案。这个项目里我们不需要那些高并发、分布式之类的复杂特性，Spring Boot 自带的 Web 能力就完全够用，而且它的自动配置能让我们把更多精力放在业务逻辑上。

第三，部署和运维相对简单。Spring Boot 最终打成一个可执行 JAR 包，服务器上只要装了 JDK，一条java -jar命令就能跑起来，对部署环境的要求很低。这一点在后来的实际部署中省了很多事。

2.2 前端框架为什么用 Vue 而不是服务端模板

最初老师提过一个想法：能不能用传统的 JSP 直接做，这样不用搭两套环境？我当场否了这个方案。

原因有两个。第一，这个系统有大量的异步交互：文件上传进度、评分按钮的即时反馈、列表的筛选切换、排行榜的实时刷新。如果用 JSP 做，每交互一次就刷新页面，体验会比较生硬。第二，Vue 的组件化开发特别适合这种“页面结构相似但状态不同”的场景。比如作品卡片在“广场页”和“我的作品页”都要用，但一个展示全部作品、一个展示当前用户自己上传的，抽成公共组件后只需要通过 props 控制数据来源就行。

具体选型我用了Vue 3 + Vite + Element Plus。Vue 3 的 Composition API 在处理评分状态、登录状态这类跨组件共享数据时比 Options API 更顺手，配合reactive和ref，代码写在单文件组件里很清晰。Element Plus 组件库则帮助我们快速搭出了 el-table、el-form、el-upload、el-rate 这些评分相关的核心界面，表格 + 表单 + 上传 + 星级评分四件套正好覆盖了系统的全部交互需求。

2.3 数据库设计：四张核心表

数据库我用的是 MySQL 8.0，建了四张核心表：用户表、作品表、评分表、作品分类表。分类表是为了让不同课程、不同赛道的作品分开排名，这在实际使用中很有用。

用户表和作品表不用多说，重点说一下评分表的设计：

CREATE TABLE `score` ( `id` BIGINT AUTO_INCREMENT PRIMARY KEY, `work_id` BIGINT NOT NULL, `judge_id` BIGINT NOT NULL, `score` INT NOT NULL, `comment` VARCHAR(500) DEFAULT NULL, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY `uk_work_judge` (`work_id`, `judge_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

评分表里最关键的是uk_work_judge这个唯一索引。一个评委对同一个作品只能给一次分，这个约束在数据库层面直接锁死。很多同类系统在应用层用“先查后插”来判断是否重复评分，但并发情况下容易出漏子，直接在数据库里加唯一索引才是最稳妥的。

有了这个唯一索引，后端的评分接口就简单了：先用findByWorkIdAndJudgeId查一下，如果存在就直接返回“该作品已评分”，不存在就插入新记录。即便两个并发请求同时进来，数据库的唯一索引也会拦住第二个插入，抛出 DuplicateKeyException，我们再捕获这个异常做友好提示即可。

3. 后端核心实现：上传、评分防重与排行榜统计

3.1 文件上传：不只是存文件那么简单

作品上传是第一个让我觉得“不能想当然”的功能。当时我最初的想法很简单，接收 MultipartFile，然后写到本地某个目录就完事了。但真正实现时，需要考虑的问题至少有四个：

第一，文件存储路径怎么组织？不建议把所有文件直接丢到一个根目录下，时间长了文件数量会非常庞大。我按年/月分目录存储，文件名用 UUID 重命名，避免中文文件名和重名造成的乱码与覆盖问题。这样既方便排查，也利于后续做备份策略。

@PostMapping("/api/work/upload") public Result upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return Result.error("文件不能为空"); } String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String newFileName = UUID.randomUUID().toString().replace("-", "") + ext; String datePath = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyy/MM")); String relaPath = "/upload/" + datePath + "/" + newFileName; File dir = new File(uploadDir + "/" + datePath); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(uploadDir + "/" + relaPath)); String url = fileProperties.getUrlPrefix() + relaPath; return Result.success(url); }

第二，上传大小限制。Spring Boot 默认的单个文件上传上限是 1MB，如果学生传一个十几 MB 的视频，会直接报错。所以我在application.yml里调整了限制：

spring: servlet: multipart: max-file-size: 50MB max-request-size: 100MB

对于纯图片作品来说 50MB 完全够用，如果碰到视频类作品 50MB 也是合理范围。这个限制值是可以按实际业务调整的，但在项目上线前一定要先和需求方确认清楚，否则学生在线上传时频繁失败，体验会非常差。

第三，文件类型要不要过滤？这种内部系统不需要像商业平台那样做严格的文件类型白名单，但如果完全不管，学生传上来一个乱七八糟的格式，评委下载下来都打不开。我的做法是：在后端做一个简单的扩展名白名单校验，常见的文档（doc、docx、pdf、ppt）、图片（jpg、png、gif、webp）、视频（mp4、avi、mov）都放行，同时把文件类型存到数据库里，方便前端决定用图片预览组件还是视频播放组件还是普通下载按钮。

3.2 评分接口：唯一索引兜底 + 业务校验

评分接口是整个系统逻辑最核心的部分。前端传过来的是作品ID、分数和评语，后端要做三步操作。

第一步，校验评委身份。通过 JWT 从当前上下文中拿到正在操作的评委ID，然后通过角色判断是否是评委，如果不是，直接返回权限不足。

第二步，校验作品状态。只能给“已审核通过”的作品打分，还在“待审核”状态或者“已下架”状态的作品不能参与评分，否则会出现学生故意上传一个违规作品诱导评委打分的场景。

第三步，插入评分记录。插入之前先查一次是否已评分，如果已评分就返回提示；如果没评分就直接 insert。正如前面说的，即便有并发冲突，数据库的唯一索引也会兜底。

@Transactional public ScoreResult submitScore(Long workId, Integer score, String comment) { Long judgeId = SecurityUtils.getCurrentUserId(); if (!securityService.isJudge(judgeId)) { throw new BizException("无评分权限"); } if (score == null || score < 0 || score > 100) { throw new BizException("分数必须在0到100之间"); } if (workService.getWorkStatus(workId) != WorkStatus.APPROVED) { throw new BizException("该作品当前不可评分"); } if (scoreRepository.findByWorkIdAndJudgeId(workId, judgeId).isPresent()) { throw new BizException("您已经对该作品评过分"); } try { Score saved = scoreRepository.save( new Score(null, workId, judgeId, score, comment) ); // 更新作品的平均分与评分人数 workService.updateScoreStat(workId); return new ScoreResult(saved.getId()); } catch (DuplicateKeyException e) { throw new BizException("您已经对该作品评过分，请勿重复提交"); } }

这里有一个容易被忽略的细节：评分提交之后要立即更新作品表里的平均分字段。如果没有这个冗余字段，查询排行榜时需要实时AVG()聚合，虽然数据量小也能跑，但接口响应会慢一些，而且每次按平均分排序还要连表子查询，SQL 写起来也比较绕。直接在作品表加avg_score和score_count两个冗余字段，每次评分后同步更新，查询排行榜就简单多了。

3.3 排行榜统计：平均分 + 人数 + 热度的合理组合

排行榜不能只看平均分，这一点是我和老师讨论后确认的。如果只看平均分，一个只被1个人打了100分的作品，排名会压在50个人打了95分的作品上面，显然不合理。所以最终的排行规则是综合排序：主排序用平均分，但平均分相同的情况下按评分人数降序排；另外再加一个“人气值”，等于评分人数加浏览数，用于首页的热门推荐列表。

主排行榜的 SQL 很简单：

SELECT w.* FROM work w WHERE w.status = 1 ORDER BY w.avg_score DESC, w.score_count DESC, w.create_time DESC LIMIT #{offset}, #{limit}

这个 SQL 在数据量几百条、几千条时性能完全没问题。如果以后作品量涨到几万条，再考虑在avg_score字段上加索引或者引入 Redis 缓存。

3.4 角色权限：基于 Spring Security + JWT 的轻量方案

权限方案我选了 Spring Security + JWT。刚开始的时候想过用 Shiro，但 Spring Security 在 Spring Boot 3 时代的集成更顺滑，而且@PreAuthorize注解的方式控制接口权限很直观。

核心思路是：登录接口返回一个 JWT，前端存储在 localStorage 里，每次请求在 header 里带Authorization: Bearer xxx。后端通过过滤器解析 JWT，把用户ID和角色放进SecurityContext，然后在 Controller 方法上用注解控制访问权限：

@PostMapping("/api/score/submit") @PreAuthorize("hasRole('JUDGE')") public Result submitScore(@RequestBody SubmitScoreRequest request) { return Result.success(scoreService.submitScore(request)); }

角色我用了三个常量：STUDENT、JUDGE、ADMIN。学生可以调用上传、浏览类接口；评委额外拥有评分类接口；管理员则拥有审核、下架、用户管理类接口。整个角色体系通过 Security 配置类统一声明，没有散落到各个 Controller 里，后期维护非常省心。

4. Vue 前端落地：页面组织、状态共享与上传组件细节

4.1 路由与页面结构

前端项目结构我按功能模块拆分，不是按页面组件类型硬拆。页面路由如下：

• /login—— 登录注册页
• /works—— 作品广场页（所有人都能看）
• /works/:id—— 作品详情页（作品展示 + 评分入口）
• /ranking—— 排行榜页
• /profile—— 个人中心（学生管理自己的作品）
• /admin—— 管理后台（管理员专用）
• /judge—— 评委工作台（已评/未评列表）

路由守卫用了 Vue Router 的beforeEach钩子，根据本地存储的角色信息判断能否进入对应页面，不能进入的直接重定向到首页。这种前端路由守卫只是用户体验层面的拦截，真正的安全校验永远在后端接口上，这一点要在文档里和前端同学讲清楚。

4.2 axios 封装：请求拦截与统一错误处理

所有接口请求我都封装在一个统一的 axios 实例里。主要做两件事：请求拦截时自动带上 JWT，响应拦截时统一处理 401 和 500 错误。

service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = `Bearer ${token}` } return config }) service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.msg || '请求失败') return Promise.reject(new Error(res.msg)) } return res }, error => { if (error.response?.status === 401) { localStorage.removeItem('token') router.push('/login') } else { ElMessage.error(error.response?.data?.msg || '网络异常，请稍后再试') } return Promise.reject(error) } )

这个封装的好处是，业务组件里只需要调用workApi.getList()就能拿到res.data，所有关于 token 和错误弹窗的逻辑都收敛到了一个地方，团队协作时代码风格也非常统一。

4.3 作品上传组件：进度条 + 类型控制 + 链接回填

上传组件用的是 Element Plus 的el-upload。但它的默认行为是“选完文件立刻上传”，而我们这里需要等待用户填写作品标题和简介，再点击“发布作品”按钮时才真正上传。所以我没有用el-upload自带的自动上传模式，而是把auto-upload设为 false，然后自己维护一个待上传文件列表。

<el-upload ref="uploadRef" :auto-upload="false" :limit="1" :before-upload="beforeUpload" accept=".jpg,.png,.gif,.pdf,.doc,.docx,.mp4,.zip" drag > <div class="upload-tip">将作品文件拖到此处，或点击选择文件</div> </el-upload>

在提交发布时，先拿到选择的 File 对象，调用/api/work/upload上传，拿到返回的文件 URL 后，再调用/api/work/publish把标题、简介、文件 URL 一起提交。这种“先传文件再提交业务数据”的方式，比直接把文件塞进业务提交请求里更灵活，后续上传进度也更好控制。

before-upload里我做了文件大小预检，超过 50MB 直接拒绝并提示，避免用户等了很久上传才发现失败：

const beforeUpload = (file) => { const maxSize = 50 * 1024 * 1024 if (file.size > maxSize) { ElMessage.warning('文件大小不能超过 50MB') return false } return true }

进度条通过on-progress事件控制，当法上传大视频时，用户能直观看到进度条在走，就不会反复刷新页面了。

4.4 评分交互：星级组件提交后锁定

评分页面我用el-rate做星级打分组件，同时旁边配一个数值显示当前分数，点击“提交评分”按钮后，调用评分接口，成功后把按钮置为禁用，状态改成“已评分”。

这里要注意一个状态同步的问题：用户在作品详情页评分成功之后，如果再进入另一个作品详情页，评分组件不能把上一次的评分状态带过来。我在每个评分组件挂载时，根据当前作品 ID 动态查询“该评委是否已评分”，如果已评分就直接显示已有分数并禁用组件，如果没评分则恢复可操作状态。这个逻辑很小，但很容易被忽略，一旦漏掉，评委就会看到一个重置过的可评分组件，以为可以重复评分，很困惑。

5. 联调与部署踩过的三个坑：跨域、上传限制和并发评分

5.1 前后端联调时的 CORS 问题

前端跑在http://localhost:5173（Vite 默认端口），后端跑在http://localhost:8080，联调时第一个遇到的就是跨域问题。浏览器会拦截前端发出的 Ajax 请求，报错信息大家都见过：Access to XMLHttpRequest ... has been blocked by CORS policy。

解决方式是在后端加一个全局 CORS 配置：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOrigin("http://localhost:5173"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

有一个细节值得提醒：如果前端请求携带了Authorization请求头，addAllowedHeader("*")在部分 Spring Security 版本里会被识别为“不允许通配符加凭证”，需要显式把请求头列出来，或者使用allowedHeaders("*")配合allowCredentials(true)的兼容写法。这个坑我当时调了小半天才定位清楚。

不过在正式部署时，前后端是用 Nginx 同域部署的，跨域问题就自然消失了，因为所有请求都走了同一个端口，Nginx 把/api反代到后端服务，静态资源直接本地返回。这个 CORS 配置只是开发期用。

5.2 上传限制的三个层级：Spring Boot、Nginx、Tomcat

文件上传大小限制不是一个地方能完全控制的，它实际上是一个链路：前端、后端、反向代理层都可能限制。后端的max-file-size我上面已经说过；但部署时还遇到了 Nginx 默认上传上限的问题。

Nginx 配置中，默认的client_max_body_size是 1MB。也就是说，即使 Spring Boot 允许上传 50MB，如果 Nginx 没改这个参数，请求在 Nginx 那一层就被拦下来了，返回 413 Request Entity Too Large。这个问题在本地开发时根本不会出现，只有部署到服务器上才会暴露。

server { listen 80; server_name your-domain.com; client_max_body_size 50m; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /upload/ { alias /data/app/uploads/; } }

这里有另一个隐蔽的点：Spring Boot 内嵌的 Tomcat 也有一个max-swallow-size的配置，虽然它默认不限制上传大小，但如果你用了自定义的TomcatConnector配置，要注意别误设了限制。嵌入式 Tomcat 在大多数情况下不需要单独调，但知道有这么一层存在，排查问题时思路会清晰很多。

5.3 并发提交评分：数据库唯一索引是唯一可靠的保证

有一次模拟测试中，我们同时用两个浏览器标签页对一个作品发起评分请求，结果发现两个请求都返回了“评分成功”，但数据库里只有一条记录。这个现象其实最危险的地方不是评分成功提示错误了，而是有一个用户明明只评了一次，前端却认为他评了两次，导致他觉得自己的第二次分数被系统吞了，反复点击提交，又反复报“已评分”，体验非常差。

这个问题的根源在于：如果应用层用“先查后插”，两个并发请求可能在“查”的阶段都拿到不存在，然后都往 insert 走，由于数据库的唯一索引，最终只插入成功一条，另一个 insert 抛异常。但异常是关键——如果对重复键异常处理不好，前端收到的就会是 500 错误，而不是友好的业务提示。

我在前面代码里已经通过try/catch(DuplicateKeyException)做了处理，这时前端会收到“您已经对该作品评过分，请勿重复提交”的提示。测试下来，无论是并发还是连续点击，用户都能得到正确反馈。这种场景下，任何应用层的锁或者标志位都没有数据库唯一索引可靠，因为应用是多实例并发，只有数据库是全局统一的。

6. 评分公平性设计：从“人人可评”到“评委打分”

6.1 初版设计的失误

项目第一版我做了一个很天真的设计：只要登录了，所有人都可以打分，想着这样参与度高一些，分数也更有参考意义。结果测试阶段就暴露了问题——学生在内部测试群里互相拉票、互刷高分，导致排行榜被个别刷分作品占据，老师们普遍不认可这个排名。

这个教训让我意识到，评分系统的公平性设计必须和技术功能一样重视。虽然这是一个内部系统，但一旦涉及评比、竞争、排名，人性中的博弈就会显现。系统不能假设所有人都是善意的，必须从规则上把刷分的口子堵住。

6.2 最终的权限与投票规则

经过和老师反复讨论，我们最终落地了以下规则：

• 学生可以上传作品、浏览作品、查看排行榜，但完全没有评分权限。
• 评委老师可以评分，每个评委对同一作品只能评一次，提交后不可修改。
• 每个作品至少需要3个评委评分，分数才计入排行，避免“一人独打分”导致的失真。
• 管理员可以重置某个作品的评分记录，以便处理“评错分”或“恶意评分”的异常情况。
• 评分结束后（按截止日期判断），系统自动锁定评分入口，排行榜冻结。

这些规则的背后是同一个目的：让这个分数尽量反映作品质量，而不是人脉广度。一个作品至少要3个评委评分才进入排行榜这条规则，直接避免了“某个作品只有1个评委给了100分就排第一”的荒谬情况。

6.3 评委工作台的实现

为了配合上述规则，我为评委单独设计了一个工作台页面。页面的核心是一个分栏列表：左侧显示“待评分作品列表”，右侧显示“已评分作品列表”。评委在左侧点击作品进入详情，评分提交后，该作品自动从左栏移动到右栏，并标记已评分数。

这个交互看似简单，但实现时要在前端处理好列表的状态更新。我用了 Vue 3 的reactive来维护两个列表数组，评分成功后从“待评列表”里过滤掉该作品，同时推入“已评列表”并更新分数展示。因为数据量不大，前端直接用内存状态管理就足够了，不需要引 Vuex/Pinia 这种重量级状态库，这也是小项目里“够用就好”的一个典型例子。

7. 项目上线前后的经验沉淀

整个项目从需求梳理到上线部署，前后大约用了一个半月。其中有半个月是在开发和联调，剩下时间花在了测试、修 bug 和部署上。最后总结几条我个人的经验，供后面做类似系统的人参考。

第一，这类内部系统的成败关键从来不是技术多炫，而是业务规则是否清晰。评分规则、身份权限、文件大小、作品状态流转，这些业务规则的优先级要排在技术架构之上。建议在动手写代码前，先用一张表格把所有角色所有操作列出来，和需求方逐条确认。

第二，上传功能一定要提前做“全链路限制检查”。前端限制、后端限制、Nginx 限制、超时设置，任何一个节点没设置好，用户上传大文件就会失败。这类问题有个共同特征是：本地一切正常，部署到服务器就挂了，原因就在于多了一层 Nginx 或网关配置。排查这种问题时，建议按“浏览器 -> Nginx -> 后端 -> 数据库”的链路逐层看日志和返回状态码，效率最高。

第三，数据库的唯一约束是数据的最后一道底线。像评分这样“一次操作不可重复”的业务，一定不能只依赖应用层判断，必须配合数据库唯一索引。我在多个项目里验证过，这是最简单、最可靠、最不容易出错的方案，强烈建议在所有类似场景里直接采用。

另外一个小建议是：如果需求方允许，在上线前先找一小批真实用户（比如三五个学生、两个老师）试用几天，收集反馈再正式推广。这个系统第一版上线后，老师们反馈最多的其实是“作品列表能不能按分类筛选”这种小需求，提前试用的好处就是能在小范围内快速迭代优化，避免在大规模使用后手忙脚乱。

这个评分网站本身只是一个小项目，但它的开发过程几乎覆盖了前后端分离开发中的典型问题：权限设计、文件上传、并发控制、跨域调试、服务器部署。做完这个项目之后我也发现，很多所谓“简单的小需求”，只要你把业务场景吃透、把边界情况想清楚，做出来的系统和未经思考就堆代码的结果会有本质区别。希望这篇记录能帮到你，也欢迎有类似项目经验的朋友一起交流更优的评分策略和实现思路。