企业官网建设流程全解析

1. 项目定位与整体设计思路

每到奖学金评审季，高校学工办的工作量基本都会爆炸。学生在不同系统间反复填表、辅导员收材料收到手软、院系审核靠人工对比成绩单、公示前还要挨个打电话核实材料。这些场景拼到一起，就是“基于vue+springboot+nodejs的学生评奖评优管理系统”要解决的业务痛点：把评奖评优从纸质填报、人工审核、线下公示，整体搬到线上，做到申报有入口、审核有留痕、排名有依据、公示有期限。

这个项目最适合三类人参考：一是高校信息化部门或软件公司里正在做类似教务系统的开发者，二是拿这个题目做毕业设计、课设的学生，三是在企业内部做审批流、评选类系统的后端开发。全文会顺着“为什么这么设计”和“具体怎么落地”两条线展开，既能帮你把整体思路理顺，也能直接抄作业式地复现一套可用系统。

先说清楚一件事：这个项目的关键词不是单一技术栈，而是“基于vue+springboot+nodejs”的混合架构。很多初次接触的人会问，既然后端已经有Spring Boot了，为什么还掺一个Node.js进来？这恰恰是这类项目最值得聊的部分。评奖评优系统要对接学校的统一身份认证、要做定时通知推送、要做大体积Excel的导出聚合，这些功能如果全部塞进Java主服务里，会导致主服务越来越重，排队等待的任务一多，连学生提交申报这种核心操作都会被拖慢。用Node.js做一层轻量级的BFF（Backend For Frontend）和服务任务层，把认证代理、消息推送、批量导出这些边缘职责剥离开，Jave主服务只做业务核心逻辑，才是这套架构的真正价值。

1.1 评奖评优系统要解决的业务问题

评奖评优听起来是一个很传统的管理场景，但实际操作中的流程链条非常长。以常见的奖学金评定为例，完整链路是：学校发布评定通知 → 学院下发细则 → 学生提交申报材料 → 辅导员核对基本资格 → 院系评审委员会打分 → 学院公示 → 学校复核 → 发文表彰。传统做法里，这整条链路的每一步都可能出问题。

第一，学生申报材料散落各处。获奖证书是一张照片，竞赛证明是一个PDF，成绩单得单独导出，志愿时长可能还在另一个系统里。收集起来全靠聊天软件传文件，一个学生七八份材料，一个班五十个人，材料总数直接冲到几百份，命名格式五花八门。第二，审核过程不透明。材料交上去之后，学生不知道流程走到哪一步了，辅导员收到材料后要反复通知补正，双方都在“黑盒”里猜进度。第三，排名计算容易出错。综合成绩通常包含学业成绩和附加分两部分，学业成绩从教务系统同步过来，附加分靠评审委员手动打分，人工算分难免有口径不统一的地方，同一张证书在不同班级加的分可能不一样。第四，公示环节难留痕。线下贴出的公示照片保存几年就模糊了，有质疑时拿不出过程记录。

这套系统的设计目标，就是把上面所有线下的、人工的、难以追溯的环节全部变成线上的、可查的、留痕的流程。学生只需一次性填写申报表并上传材料附件，系统自动锁定申报窗口；辅导员只需进入审核列表逐条点击通过或退回，所有操作自动写入审核日志；排名由系统按预设权重自动计算，不再靠Excel手工排序；公示到期自动关闭，申诉记录独立存档。一句话总结：这个系统的核心是流程引擎加数据沉淀，技术只是手段。

1.2 为什么选择Vue + Spring Boot + Node.js的组合

技术选型没有绝对的“最优解”，只有“在当前业务和团队条件下更合适”。评奖评优这类管理系统一不追求超高并发，二不涉及复杂机器学习算法，三对性能的敏感度也没到毫秒级，所以选择成熟稳定、社区资料多的技术栈是更合理的策略。

前端选Vue，核心原因是上手曲线平滑、组件生态完整。评奖评优系统中有大量表单页面、列表页面、审核操作页面，Vue的响应式数据绑定加上Element UI / Element Plus这类组件库，能极大缩短页面开发时间。对学校信息化团队或做课设的学生来说，“能快速把界面做出来”比“性能极致”更重要。

后端主服务选Spring Boot，主要看中三点：完善的权限生态、成熟的事务管理、稳定的任务调度。评奖评优涉及学生、辅导员、院系管理员、校级管理员、评审委员会五类角色，权限控制是刚需，Spring Security加自定义注解可以很规范地实现。成绩和附加分的写入、审核状态的流转、公示定级这些操作都涉及多表变更，Spring的事务注解能让开发者少操心数据一致性。

Node.js在这个架构里的角色，不是“第二个后端”，而是“辅助服务层”。从我实际接触过的类似项目来看，它通常承担三件事。一是认证代理，学校有统一的身份认证服务，前端登录时要对接这个校园认证系统，Node.js用Express写一层薄薄的代理转发，比Java那边做一整套认证SDK集成更轻快。二是定时任务与消息推送，比如申报截止前24小时自动提醒未提交的学生，公示启动时自动通知相关班级，这类轻量任务放在Node.js的定时器生态里，写起来非常顺手。三是大数据量导出聚合，评奖结果确定后需要生成全校汇总的Excel和获奖材料压缩包，Node.js的流式处理加子进程机制，可以在不撑爆主服务内存的情况下完成文件打包。

这样的混合架构不需要引入额外复杂的中间件，开发和运维成本都可控。整套系统拆成前端服务、Java主服务、Node.js辅助服务三块，每一块功能边界清晰，出了问题也知道去哪查。

1.3 整体架构与模块划分

按照实际开发时的习惯，我先把整个系统划分成了六个核心模块，这六个模块基本覆盖了评奖评优业务从配置到归档的全流程。

• 系统管理与权限模块：用户管理、角色管理、菜单权限、数据权限，支撑五类角色的登录与操作隔离。
• 奖项与批次配置模块：创建奖项类型、配置评选批次、设定申报时间、设置综合成绩权重和附加分规则。
• 学生申报与材料上传模块：学生按批次提交申报信息，上传证书、成绩单等附件，支持草稿保存和重复申报。
• 多级审核与流程追踪模块：辅导员、院系、校级三级审核，状态机控制进度，退回补正留痕，学生可实时查看当前节点。
• 排名计算与公示管理模块：按权重自动计算综合成绩并排序，生成拟获名单，推送公示，到期自动关闭，处理申诉反馈。
• 数据统计与导出归档模块：获奖数据看板，Excel导出，材料压缩包归档，供学院和学校留档备查。

从部署视角看，前端项目构建后由Nginx托管，Java主服务以内嵌Tomcat方式运行，Node.js辅助服务独立进程运行，三个服务之间通过网络接口通信。Java主服务是业务核心，所有评审流程、审核记录、排名计算都在这层完成；Node.js服务只接收Java转发的辅助任务，比如发送通知、导出归档文件。数据库用MySQL，缓存和部分会话用Redis。这套架构不算复杂，但每一层都有明确职责，后续扩展或排错都有边界可循。

2. 核心业务拆解与数据模型设计

系统的功能模块列完之后，真正设计数据库时才有挑战性。评奖评优系统的数据模型和普通CRUD系统的最大区别是：它不仅要存当前的结果，还要存过程、存版本、存审核轨迹。比如一名学生第一次申报时上传了材料A，辅导员退回要求补充材料，学生二次提交时上传了材料B，系统必须能查到材料B是第二版，且第一版材料A依然可追溯。这种过程性数据需求，决定了核心表的设计方式。

2.1 评奖评优的业务主链路

在设计数据表之前，先把业务主链路完整梳理一遍，这一步不做干净，后面写SQL和业务代码时一定会返工。

系统里最重要的一条链路是：管理员创建奖项和批次 → 学生填写申报单并上传附件 → 申报单进入“已提交”状态 → 辅导员初审（通过或退回） → 院系评审（打分或复核） → 校级终审 → 系统按权重自动计算排名 → 生成拟获名单 → 进入公示期 → 公示结束无异议 → 定级归档。

这条链路里隐藏着几个关键约束。第一，批次具有时间窗口，申报期内学生可以撤回修改，申报截止后不能再动。第二，每个审核节点必须保留操作人、操作时间、操作意见，这是后续处理投诉和申诉时的依据。第三，公示期内只显示获奖名单的拟公示版本，公示结束后才能生成正式定级结果。第四，一名学生同批次同奖项只能提交一条有效申报，重复提交必须以后台逻辑拦截。

这些约束直接决定了数据表设计中必须有状态字段、版本字段、审核日志表、批次配置表。状态机一旦定死，后面写前端按钮显隐、后端接口校验，都依托同一套状态定义。

2.2 核心数据表的设计思路

有了业务主链路，就可以设计核心表结构了。这里我按实际建表时最常用的方式整理，字段名和类型尽量贴近通用规范，开发时可直接参考。

declare_form表的status字段是整个系统的灵魂。我把状态值统一为：0草稿、1已提交、2辅导员通过、3院系通过、4校级通过、5公示中、6已定级、7已归档、-1被退回。回到被退回时，系统会同时记录退回意见，学生修改后重新提交，version字段自增，所有历史版本仍可查询。这个设计在答辩或实际项目验收时非常加分，因为它体现了申报材料“全过程可追溯”的业务价值。

排名计算不另建表，而是在declare_form表中加rank_no字段。这样高校在公示时只需按batch_id和rank_no排序，就能直接导出拟获名单。要注意的是，排名明细结果要定期做全量快照，否则后期有人篡改历史数据时，无法证明公示时点的名次是什么。我在项目里采用的方式是：公示启动时，把declare_form中关键字段复制到batch_snapshot表，作为公示时点的不可变依据。

2.3 评审算法与附加分计算规则

评奖评优的核心不只是“提交和审核”，最终要输出一个有公信力的排名。排名算法必须透明，我在系统里用的是最常见的加权综合分模型：综合成绩 = 学习成绩×权重 + 附加分×权重。

以某企业奖学金为例，学习成绩权重70%，附加分权重30%，学习成绩取该批次周期内必修课加权平均分，附加分包括学科竞赛、学术论文、发明专利、文体活动、志愿服务五类。每所学校的加分规则差异很大，所以score_rule表里必须预留可配置空间：设定奖项对应权重、必修课门数下限、附加分总分上限。这样当某个奖项的评审细则调整时，只需改配置表，不用动代码。

附加分计算是排名公平性的高危区。我的做法是学生自报加分项并上传证明材料，辅导员初审只核验材料真实性，院系评审委员会复核加分项对应等级，校级终审对超高加分项抽查。整个过程中，bonus_score字段只在院系评审通过后写入一次，不得由学生自行修改。例如一个学生提交“省级竞赛一等奖”加分项，系统按规则自动映射为10分，辅导员看到上传证书扫描件，确认后改为确认状态，最终计入总分。所有这些操作记录都写入audit_record表，任何时候有人提出异议，都能把所有环节拉出来对质。

2.4 权限模型的落地方式

权限设计直接影响系统的安全性和操作的规范程度。评奖评优系统的角色天然呈现金字塔结构：学生只能管自己的申报，辅导员管本班数据，院系管理员管本院数据，校级管理员管全校数据，评审委员会只看成绩和加分项，没有编辑权限。

我用的是RBAC模型加数据权限范围控制。角色权限负责“能不能进这个菜单”，数据权限负责“能看哪些行的数据”，两者配合才算完整。举例来说，辅导员角色能进入审核列表页面，但列表数据默认只加载该辅导员管辖班级的学生申报；校级管理员能进入全部批次列表，并可以进行归档操作。

实现上，后端接口配合自定义注解 + Spring AOP拦截，菜单按钮权限硬编码在系统初始化SQL里，数据权限则通过MyBatis拦截器动态拼接SQL条件。核心代码片段参考如下：

@Permission(role = {"ADMIN", "COLLEGE_ADMIN"}, dataScope = DataScope.SELF) @PostMapping("/batch/create") public Result createBatch(@RequestBody BatchDTO dto) { // 只有管理员可以新建批次 }

拦截器里会先验证当前登录用户的角色是否匹配注解声明，再从Redis中读取用户归属信息，拼接数据范围条件。比如辅导员访问“学生申报列表”时，拦截器自动在SQL后追加AND class_id = #{currentUserClassId}，开发时几乎不用在业务代码里重复写权限判断，也不容易漏掉某处校验。

需要额外提醒的是，不要只依赖前端路由守卫来控制权限。前端路由只是菜单层面的遮挡，真正有效、防绕过的一定是后端的接口级权限校验。我用一个简单的请求拦截过滤器，凡是访问评奖评优核心接口的请求都先过一遍权限校验中间件，避免学生绕过前端直接构造请求修改审核结果。

3. 从零搭建的实操流程与关键实现

前面把架构和设计思路摊开了，这一部分直接用“从一个空环境开始搭一套可运行的评奖评优系统”的视角，把实操流程完整过一遍。每一步我都写了当时踩过的坑和调整过的方案，照着做能少走不少弯路。

3.1 环境准备与项目初始化

开发这套系统，本地环境至少需要：JDK 17（Spring Boot 3.x对JDK版本有硬性要求，用JDK 8跑新版反而折腾）、Node.js 18以上、MySQL 8.x、Redis 6.x，前端工程管理工具用npm或pnpm均可。

具体初始化步骤我按实际执行顺序列出：

1. Java后端工程：直接用Spring Initializr创建，选择Spring Web、MyBatis、MySQL Driver、Redis、Lombok依赖，打包方式选Jar。
2. 前端工程：用Vite创建Vue 3项目，命令是npm create vite@latest award-web -- --template vue，装好Vue Router、Pinia、Axios，再加Element Plus组件库。
3. Node.js辅助服务：单独建一个名为award-bff的Express项目，目录结构和Java主服务分离，后续同目录下启动多个服务即可。
4. 数据库初始化：创建award_system数据库，按前面列出的核心表结构建表，注意给状态字段加默认值，审核日志表加索引，否则数据量上来后查询会很慢。

这里特别强调一个容易忽略的细节：项目里所有的配置文件不要提交到仓库，尤其是数据库密码和JWT密钥。我最初开发时直接把配置写在application.yml里，后来不得不写脚本清理提交记录，非常麻烦。正确做法是本地保留一个application-local.yml用于开发，部署时用环境变量注入数据库地址和密码，保证敏感信息不进仓库。

3.2 奖项批次配置与批量导入

评奖评优系统每年要维护几十个奖项和多个批次的配置。如果每次都在界面里手动创建一个奖项，再手动创建批次，管理员会非常烦躁。更好的做法是支持Excel批量导入，管理员在系统里下载模板，填好奖项、批次时间、名额、权重等字段，一次导入生成多条配置记录。

后端导入用Apache POI还是EasyExcel，我的建议是优先用EasyExcel。POI在大量数据场景下内存占用高，容易触发OOM，EasyExcel采用SAX模式逐行读取，更适合这种秒级导入场景。核心逻辑代码可以参考如下结构：

public void importBatchExcel(MultipartFile file) { EasyExcel.read(file.getInputStream(), BatchImportVO.class, new BatchImportListener(batchService)).sheet().doRead(); }

导入时一定要做两件事：一是校验模板中的奖项类型名称能否在数据库中找到对应记录，找不到的直接在导入结果里标记失败原因；二是校验批次时间窗口是否与已有批次冲突，同一奖项同一时间段的批次不允许重复创建。前端导入后展示成功和失败明细，管理员可以单独修正失败行后再次导入，不用整张表重新来过。

细粒度配置上，批次状态也建议区分“草稿”“已发布”“进行中”“已截止”。草稿状态允许管理员修改所有字段，已发布状态只允许延长截止时间，已截止状态不允许任何编辑。这样设计能避免管理员误操作造成学生申报窗口突然变化，也符合高校管理流程中对“通知发布后不能随意改”的要求。

3.3 学生申报核心功能实现

学生端页面是整套系统使用频率最高的模块，既要简洁，又要能承载复杂的申报流程。前端实现时，申报页面拆成三块：基本信息区、成绩展示区、附加分与材料上传区。基本信息直接从学生账号档案里带出，不需要重复填写；成绩展示区默认显示系统从教务同步的平均学分绩点；附加分区域按五类加分项分别展开，每个加分项下面有“上传证明材料”按钮。

后端接口设计上，申报提交接口必须考虑防重复提交和状态校验。学生点击“提交申报”后，后端先检查批次状态是否为“进行中”，再检查该生该批次是否已有有效申报单，防止点击两次生成两条数据。用Redis做幂等键是一个高效方案：前端生成请求唯一ID传入，后端在Redis中以这个ID为key加锁，重复请求直接被拦截。

文件上传部分是另一个坑。评奖评优的材料通常有不少证书扫描件和PDF，一个附件往往几兆甚至十几兆。如果直接走Spring Boot的接口并同步存到服务器目录，上传大文件时客户端容易超时，而且服务器在处理文件时还会占用大量连接资源。我的方案是改造为前端直传对象存储服务，上传请求先拿一个预签名URL，前端把文件流直接传到存储服务，上传成功后把文件URL提交给业务接口。这样做的好处是附件上传和业务提交解耦，学生上传到一半刷新页面也不会丢业务数据。

学生填报过程中的另一个体验细节是草稿机制。很多学生不会一次性填完所有内容，中途去开个证明、找导师签字，过两天再回来继续填。所以申报接口必须支持保存草稿，草稿状态下所有字段允许修改，正式提交后才进入审核状态不可自行改动。这个需求很容易被做成“先填后提交”的简单表单，但如果忘记支持草稿，实际使用中学生会频繁求助管理员重置填报状态，系统口碑会大幅下降。

3.4 多级审核与公示期实现

多级审核是这个项目最有技术含量的部分。我把审核流程设计成了一个状态机，核心状态流转顺序是：已提交 → 辅导员通过 → 院系通过 → 校级通过 → 公示中 → 已定级。

每级审核操作都写入audit_record表，插入内容包括申报单ID、审核级别、操作人、操作结果、审核意见和时间。学生端“进度查询”页面显示的每个节点，本质上就是按申报单ID查询审核记录表并按时间排序后的结果。

审核环节最容易出现的问题是并发操作。比如辅导员和院系管理员同时打开同一个学生的申报详情，辅导员点了“通过”，院系管理员同时点了“退回”，最终落库的状态以谁为准？我在实现时给declare_form表加了版本号字段，每次审核更新都会带上版本号，通过乐观锁的机制保证不会覆盖彼此的操作。如果版本号冲突，后操作的审核人会得到提示“该申报单状态已变更，请刷新后再操作”，避免人为覆盖审核结果。

公示期实现我采用定时任务加手动触发两种方式。每次公示启动时，系统自动生成公示记录并写入notice_info表，同时通过Node.js辅助服务向关联学生推送通知，告知公示起止时间。定时任务每天晚上扫描一次公示记录，把已到结束时间的公示状态自动变更为“公示结束”，同时生成定级结果。定级结果生成后，declare_form的status置为“已定级”，排名和奖项信息被锁定，任何修改都需要校级管理员审批。

3.5 导出归档与数据可视化

评奖评优流程收尾后，还有两类高频需求：一是导出获奖名单Excel，二是按奖项打包获奖材料归档。这两件事做起来都不难，但在线生成大体积文件时容易踩性能坑。

Excel导出我用EasyExcel的异步任务模式：前端点击导出后，后端先把导出任务写入任务表，返回“导出中”提示，Node.js服务轮询任务表并通过流式写入的方式生成文件，生成完成后把下载地址回写，前端再显示下载按钮。这样避免超大文件在HTTP响应中一次性生成，导致请求超时。

获奖材料归档使用Node.js的流式管道和子进程。按批次查询所有获奖学生的附件URL，用stream逐一下载并写入压缩流，边下边写，不在内存中保留整个压缩包。实测下来，一个包含几百份证书扫描件的压缩包，用这个方案可以稳定生成，不会像一次性读入内存那样直接让进程崩溃。

数据可视化层面，管理员首页展示全校获奖人数、奖项分布、各学院获奖率、附加分类型占比等指标。这部分用Vue的ECharts封装组件即可，后端提供一个统计查询接口，按学院分组统计获奖数量，按奖项类型统计申报通过率。这类统计接口是评估系统价值的直接体现，学院书记、学生处长都要看这些数据来了解评奖导向。

4. 部署与常见问题排查实录

系统开发完成只是走完一半，能稳定上线运行、遇到问题能快速排查，才是真正见功夫的地方。这一部分把部署结构和上线后我实际遇到的典型问题整理出来，算是一份可复用的运维笔记。

4.1 上线部署与容器化

评奖评优系统通常部署在学校机房服务器或云主机上，配置不需要太高，4核8G的机器就能跑起整套环境。但资源有限不代表可以随意部署，我的建议是优先容器化，减少环境差异带来的问题。

我用Docker Compose编排了整套环境，服务划分为四个容器：

• web容器：Nginx镜像，托管前端静态资源，反向代理/api请求到Java主服务，代理/bff请求到Node.js辅助服务。
• api容器：Spring Boot镜像，挂载application-prod.yml和环境变量，暴露8080端口。
• bff容器：Node.js镜像，运行辅助服务，监听3000端口。
• db容器：MySQL镜像，数据目录挂载到宿主机磁盘，保证容器重启不丢数据。

Nginx配置里要注意前端路由的History模式重写规则。Vue 3开启History路由后，直接访问内页地址会返回404，必须配置try_files $uri $uri/ /index.html;，这个坑在首次部署时几乎必踩。反向代理的/api和/bff必须分别指向Java主服务和Node.js服务，不要混成一个目标地址。

服务启动顺序也有讲究。MySQL容器先启动并完成初始化，然后Java主服务启动，最后启动Node.js辅助服务。我写了一个简单的健康检查脚本，依次探测MySQL端口、Java服务的健康检查接口、Node.js服务的存活接口，全部通过后再把Nginx代理切到新版本。这样发布新版本时不会出现前端静态文件已经更新、后端接口还在旧版的情况。

4.2 系统上线后必须要做的安全检查

评奖评优系统涉及学生个人信息和评审结果，上线前必须做一轮安全加固。我这里整理了几个最关键的检查点。

密码安全是第一关。所有用户初始密码必须设置为随机密码，并要求首次登录强制修改。密码存储用BCrypt加密，不能用MD5直接存。Redis里存放的登录Token要设置过期时间，学生端的登录态通常保持2小时，辅导员和后台管理角色保持8小时，到期自动退出重新登录。

接口访问控制必须覆盖所有写操作。尤其是审核接口、排名计算接口、归档接口，必须加上角色校验和服务端二次校验，不能只依赖前端隐藏按钮。我见过一些系统，学生直接构造POST请求就能把自己申报单状态改成已通过，这是极其严重的漏洞。另一个高发问题是批量导出接口未做权限控制，任何人都可以下载全校学生信息，这类接口一定要限制为仅校级管理员可访问。

文件上传安全同样不能松懈。在上传接口里要对文件扩展名做白名单校验，仅允许jpg、png、pdf、docx、xlsx这些业务常用格式，同时限制单个文件大小不超过20MB。Spring Boot的spring.servlet.multipart.max-file-size要显式设置，否则默认1MB会让学生传不了证书扫描件，但调高之后必须同步做文件类型检查，避免被传可执行文件。

4.3 常见问题速查表与避坑技巧

上线之后的问题排查，很多情况是有规律可循的。我把实践中遇到的典型问题整理成了一张速查表，方便开发或运维时对照处理。

避坑技巧方面，最值得提醒的一点是：审核流程中“退回”操作要特别谨慎。某次联调时，我点“退回”后直接设置了状态为“被退回”，结果学生重新提交时，版本号没有更新，导致旧审核记录被新记录覆盖。后来我在退回操作的同时强制version自增，并生成一条“退回给申请人”的流转记录，问题才解决。

另一个容易被忽略的地方是申报截止时间和服务器时区的匹配。高校一般设置晚上23:59截止，如果数据库和服务器的时区不一致，学生可能看到的是“已截止”而管理员看到的是“进行中”，制造出大量投诉。我的做法是后端统一使用“Asia/Shanghai”时区，所有时间字段存储为UTC时间戳，前端统一转换为本地时间展示，避免时区导致的系统性偏差。

数据备份也值得多提一句。评奖评优系统在评审季的操作频率高，数据价值也高，我设置了每天凌晨自动备份MySQL数据库，同时保留最近30天的备份文件。每个批次归档后，还会把该批次的申报数据、审核记录、公示记录整体导出为一份JSON快照，存放到独立的归档目录。这样即使数据库出现严重故障，也能从最近一次备份恢复，并在极端的归档数据丢失场景下，用JSON快照重建关键批次信息。

最后，关于系统上线后还需补充做的事，我的个人体会是：先保证核心流程一个月稳定运行，再逐步加统计分析、消息通知、移动端适配这些增强功能。评奖评优系统的本质是让管理流程更规范，而不是功能越多越好。把申报、审核、排名、公示这条主线做扎实，比堆一堆花哨但没人用的功能要重要得多。如果你准备开发类似的系统，先把这条主链路跑通，其他的都可以后面再加。