企业官网建设流程全解析

这几年给不少做创客教育的机构搭过内部系统，小码创客教育教学资源库这类项目几乎算得上最典型的“业务清晰、技术常规、却处处有坑”的活儿。表面上看，它就是一个资源管理后台加一个前台展示页，但真正动手之后才发现，资源库最难的从来不是CRUD，而是资源文件怎么管、权限边界怎么划、审核状态怎么流转，以及前后端分离之后那一堆说不清道不明的联调问题。

这个项目用的是SSM加Vue的组合，放在今天看不算新潮，但在教学资源管理这个场景里反而很合适：团队容易接手、部署不重、功能边界清楚。我下面把整个项目的拆解思路、数据模型、后端实现、前端联调以及部署运维的完整过程捋一遍，给准备做同类系统的朋友一份可以直接参考的路线图。内容偏实操，尽量把我知道的坑和背后的道理都讲清楚。

1. 项目定位与核心逻辑拆解

1.1 小码创客教育资源库到底要解决什么问题

先别急着写代码，得想明白这个系统是给谁用的。小码创客教育通常面向中小学编程、机器人、图形化编程、3D打印这类课程，资源形态极其多样：教案文档、PPT课件、Scratch工程文件、Python示例代码、机器人搭建图纸、器材清单、甚至是一段上课实录视频。过去这些资源散落在老师个人的电脑、网盘和微信群里，要用的时候找不到，版本还经常冲突。

资源库的核心任务就是把这些零散资源收拢到一个统一入口，让老师能上传、能检索、能下载，让学生能按课程查看资料，让管理员能审核内容、看统计。所以这个项目不是一个简单的“网盘替代品”，它必须贴合教学场景：资源要分类、要打标签、要能预览、要记录下载行为、部分资源还可能要积分或权限限制。

我在给机构做需求梳理的时候，通常会先把用户故事写出来，大概就是这几条：

• 老师上传一份Scratch课程包，填写标题、分类、标签、适用年级，提交后进入审核。
• 教研组长或管理员登录后台，看到待审核列表，点开详情确认内容合规后通过。
• 学生或老师在前台通过关键词搜索，按分类筛选，点击下载资源。
• 管理员在后台看到资源总量、各分类占比、下载排行、最近上传动态。

这些故事对齐之后，系统边界就清楚了：它不需要做复杂的在线编辑，不需要做实时互动，核心就一个字——“管”。管的对象是资源元数据、文件实体、用户行为。明确了这个定位，后面所有设计都不会跑偏。

1.2 为什么SSM+Vue这个组合仍有现实价值

每次提到SSM，总有人觉得这是“过时技术栈”。但放在教育教学资源库这个场景里，它反而是稳妥的选择。原因有几个：第一，很多高校和教育机构的现有服务器还是老环境，Tomcat加JDK8是标配，SSM在这种环境下部署特别顺；第二，团队里可能还有大量熟悉JSP和传统分层开发的同事，SSM的学习曲线比Spring Boot平滑，维护起来不慌；第三，这类系统业务复杂度不高，Spring Boot带来的自动配置优势体现不出来，反而多了一层“黑盒”感。

当然，我不是说SSM一定要硬扛。如果你完全从零开始且团队没有历史包袱，直接上Spring Boot加MyBatis Plus更省事。但如果是毕设、课程设计、或者给一个已有老系统做升级改造，SSM完全立得住。Vue负责前端交互，SSM提供接口，前后端分离之后，以后想再套一个小程序或者移动端H5，后端接口可以直接复用，这点非常重要。

这里我把几个方案做个对比，大家根据自己情况选：

从我个人的实操体验看，小码创客教育资源库这种规模，SSM的项目结构反而能让人把每一层都看得清清楚楚，出了问题也好排查。对学习者来说，SSM能帮你把Spring IOC、Spring MVC的请求流程、MyBatis的Mapper代理原理都吃透，这比“一键生成”有价值得多。

1.3 动手之前先理清MVP功能清单

做资源库最大的坑就是功能越做越多。本来只想做个上传下载，结果聊着聊着就加了在线剪辑、实时白板、消息通知、积分商城。我强烈建议第一版只做以下功能：

• 用户登录注册（区分学生、教师、管理员三种角色）
• 资源的分类管理（内置分类 + 后台可配置）
• 资源上传（标题、简介、分类、标签、封面图、文件）
• 资源审核（管理员通过/驳回/下架）
• 资源检索（关键词 + 分类筛选 + 分页）
• 资源详情与预览（图片、视频支持在线预览，其他文件提供下载）
• 收藏与下载记录
• 简单的数据统计（资源总量、分类占比、下载Top10）

这些功能做完，系统就已经能用了。像积分体系、评论问答、消息通知这些都属于“第二期”，等基础跑通了再迭代不迟。明确MVP还有一个好处：数据库表设计的时候不会为了“以后可能用到”去建一堆冗余表。

2. 数据模型与核心功能设计

2.1 用户与权限设计：三类角色的边界划分

资源库的用户模型不复杂，但有一个关键点要在建表之前想清楚：学生和老师的权限差异到底体现在哪里。我见过很多项目给用户表加一堆角色字段，代码里到处if判断，写到最后自己都晕。我的建议是：用角色字段加拦截器做粗粒度控制，够用就行。

用户表t_user可以这样设计：

• id：主键自增
• username：登录名，唯一索引
• password：加密后的密码
• nickname：显示名称
• role：角色，1学生 2教师 3管理员
• avatar：头像路径
• status：状态，0禁用 1正常
• create_time：创建时间

这里没有单独做user_role关联表，是因为角色在项目里是唯一的。如果哪天业务复杂到一个用户同时有教师和管理员身份，再拆关联表也不迟。我给某高校做类似系统的时候，曾经一上来就设计了五张权限表，结果开发了一个月发现RBAC那套完全用不上，白白增加了联调工作量。记住一句话：权限设计要为当前业务服务，不要为了“规范”而规范。

密码加密方面，千万别用MD5或者SHA1直接存。早期项目真的是这么干的，泄露一次数据库，所有用户的密码全暴露。现在统一用BCrypt，每次加密自动带盐，同一个密码两次加密结果都不一样，安全性好得多。Spring的BCryptPasswordEncoder可以直接用，不需要自己造轮子。

2.2 资源实体表：如何设计才能支持分类、标签和多文件

资源表是整个系统的核心，设计得好不好直接决定后续开发的顺畅程度。我见过最普遍的错误是把文件路径直接存到资源表的一个字段里，结果一个资源对应多个文件的时候只能塞JSON字符串或者用逗号拼接，查询和展示都特别痛苦。

正确的做法是把资源主体和文件实体分开。t_resource存资源的公共属性，t_resource_file存具体的文件。一张表结构参考如下：

t_resource（资源表）：

• id：主键
• title：资源标题
• summary：资源简介
• category_id：分类ID
• type：资源类型，1教案 2课件 3代码工程 4视频 5图片 6其他
• cover_url：封面图
• tags：标签，多个用逗号分隔
• uploader_id：上传用户ID
• status：0待审核 1已通过 2已驳回 3已下架
• download_count：下载次数（冗余统计）
• favorite_count：收藏次数（冗余统计）
• create_time：更新时间

t_resource_file（资源文件表）：

• id：主键
• resource_id：关联的资源ID
• file_name：原始文件名
• file_path：存储的相对路径
• file_size：文件大小（字节）
• file_type：文件扩展名
• sort_order：排序，用于多文件场景
• create_time

为什么要拆这张表？因为一个Scratch课程包可能包含一个.sb3工程文件、一个PPT课件、一张搭建图纸，如果都塞在资源表里，列表页查询会非常笨重。拆开之后，资源列表页只查t_resource，详情页再按resource_id一次性查文件列表，逻辑清晰、性能也好。

资源状态字段也值得多说一句。审核流看起来简单，但一定要用状态机思维去控制流转：待审核只能被管理员操作，变成通过或驳回；已驳回的资源可以编辑后重新提交，回到待审核；已下架的可以重新上架。不要允许用户在前台直接修改已审核通过的资源，要么重新走审核，要么管理员后台改。这个规则定死了，后面各种“数据不一致”的坑能少一大半。

2.3 围绕资源的业务闭环：收藏、下载、积分、统计

收藏和下载记录是资源库最基础的交互数据。我的建议是这两块都做独立表，不要只靠资源表里的count字段撑全场。t_favorite表字段很简单：id、user_id、resource_id、create_time，加上一个唯一索引uniq_user_resource就能防止重复收藏。下载记录表类似：id、user_id、resource_id、file_id、create_time。有了下载记录表，后面做个人中心“我的下载”、做管理员端的下载排行，都是顺手的事。

冗余计数字段frequency_count也不是不能用，我先说前提：要结合业务量判断。资源库系统通常并发量不大，如果每次下载都实时去download_record表count一下，也没多大压力。我一般在列表页和详情页直接用冗余字段显示次数，后台异步脚本定期从记录表重新统计一次，把结果回填到冗余字段，两边数据偶尔有偏差但可接受。这样既保证了展示性能，又不会过度设计。

积分体系这块，如果第一版要做，我建议做一个简单的t_score_record表就够了。字段包括user_id、change_type（1上传 2下载 3签到 4兑换）、change_amount（正负值）、balance_after、create_time。每次积分变动都记录流水，余额通过最近一条记录的balance_after获取。很多项目喜欢在用户表存一个score字段，然后直接加减，结果查历史记录的时候完全对不上账，这种教训太常见了。

统计功能不需要单独建表，管理员后台的大盘数据直接在SQL层面聚合就行。资源总量、今日上传数、各分类占比、下载Top10，这几条SQL写完就能出报表。真正需要预计算的是“每周新增资源趋势”这种跨时间聚合，但如果数据量不大，现查现算也完全没问题。

3. 后端SSM实现的关键环节

3.1 Maven工程结构与依赖管理

SSM项目结构我建议按单模块加包分层的做法，不必强拆多模块。之前见过一个团队一上来就搞parent、common、system、admin四个模块，结果开发了一周，连个登录接口都没跑通，光依赖调来调去就够受的。教育教学资源库的代码量撑不起多模块的复杂度，老老实实一个maven-webapp工程就够了。

包结构大概是这样的：

• controller：接收前端请求，做参数校验
• service：业务逻辑
• mapper：MyBatis的数据访问接口
• entity：数据库实体类
• dto：前端交互参数对象
• vo：返回给前端的数据对象
• config：Spring配置、拦截器配置
• util：工具类

依赖方面，核心就是这几样：spring-webmvc、mybatis、mybatis-spring、mysql-connector-java、druid连接池、jackson-databind、pagehelper分页插件、lombok。还有Java JWT或者jjwt用于鉴权。这里有个小提醒：MySQL驱动版本一定要和本地数据库版本匹配，我遇到过用MySQL 8以上版本但驱动还停留在5.1的情况，结果连接串里必须手动加cj前缀，折腾半天才发现是版本问题。

pom.xml里有一个特别容易踩的坑：依赖冲突。比如druid和log4j、slf4j之间如果不加exclusion，启动时会出现奇怪的类加载异常。我之前在一个项目里就是druid自带的slf4j和项目里显式引入的版本冲突，导致日志死活不打印SQL语句，排查了很久才发现是依赖传递的问题。所以pom里的每个依赖，尽量把不用的传递依赖用exclusion排除干净。

3.2 登录鉴权的落地方式：JWT还是Session

前后端分离项目里，登录鉴权基本就两条路：Session加Cookie，或者Token加Header。SSM时代的经典做法是Session，但放到Vue前端部署在不同域名、甚至以后要做小程序的情况下，Session跨域比较别扭，我建议用JWT。

JWT的整体流程很简单：用户提交用户名密码，后端校验通过后生成一个token返回给前端；前端把token存到localStorage，每次请求在axios请求头里带上Authorization字段；后端写一个拦截器，拦截除登录、注册之外的路径，从请求头解析token并验证有效性。

拦截器的实现有几个关键点。第一，白名单要配好：登录接口、注册接口、资源列表、资源详情这些匿名可访问的路径必须放行，否则用户还没登录连资源列表都看不了。第二，token解析失败要返回固定的JSON格式，比如code=401，这样前端拦截器能统一跳转登录页。第三，拦截器里解析出来的用户ID要放进ThreadLocal或者Request属性里，供后面的Controller直接取用，不要在业务代码里再解析一次token。

密码这一层我还是想再强调一下，后端校验密码用BCryptPasswordEncoder的matches方法，不要自己把密码拿出来做等值比较。曾经有个同事图省事，在数据库里存了明文的MD5哈希，结果被扫出来一堆弱口令，教训很深刻。

JWT生成的时候最好设置过期时间，一般2到4小时比较合适。过期后前端要能自动跳转登录页，不要让用户在一个“未知错误”的弹窗里懵掉。后端处理好过期时间戳的判断，返回一个明确的“登录已过期”code，前端axios响应拦截器统一处理即可。

3.3 文件上传与资源路径管理

资源库最核心的功能就是文件上传，这部分的坑最多。先说存储方案：不要存数据库，不要存base64，统一存本地磁盘，然后用Nginx做静态资源映射。数据库里只存相对路径。我之前见过一个项目把图片直接转base64存进MySQL，一张图几MB的文本，直接把数据库撑爆，查询速度惨不忍睹。

上传目录的结构，我习惯按日期分目录：/data/resource/upload/2025/06/17/uuid文件名。为什么用日期分目录？一方面避免单个目录文件过多导致文件系统性能下降，另一方面后续做备份和清理也方便。文件命名一律用UUID加原始扩展名，不要用用户上传的文件原名。不是怕乱，而是防止中文文件名在下载的时候出现浏览器编码问题，以及路径穿越的安全隐患。

文件类型校验要特别注意：不能只信任前端传来的文件类型，更不能只看文件扩展名。因为Content-Type是可以伪造的，扩展名也可以改。我通常在前端做一层拦截（提升用户体验），后端再做一层最终的扩展名白名单校验（保证安全）。白名单根据实际需求配置，比如图片只放行jpg、jpeg、png、gif、webp，文档放行doc、docx、pdf、ppt、pptx、xls、xlsx，工程类放行sb3、zip、rar、py、c、cpp等。

上传大小的限制在Spring配置里也需要注意。老项目经常遇到上传大视频时直接被Tomcat默认的2MB限制挡住，前端报一堆莫名其妙的错误。需要同时配置spring.servlet.multipart.max-file-size和max-request-size，一个管单文件，一个管请求体总大小。视频资源建议单独放大到500MB到1GB，具体看需求。这里有个经验：上传大文件的时候，进度反馈特别重要，否则用户看着页面没反应，很容易以为失败了。前端用axios的upload.onprogress事件可以拿到上传进度，这一点在资源库体验上非常加分。

前端上传文件时，对于大文件，有的项目会做分片上传，但我觉得教学资源库这类内部系统，单文件控制在几百MB以内，直接一次上传就够了，没必要引入分片断点续传那套复杂度。真到了需要传几个GB教学视频的规模，你更应该考虑对象存储，而不是自己折腾本地上传。

4. 前端Vue设计与联调

4.1 项目初始化与目录规划

前端用Vue，版本选择上我建议根据团队的熟悉程度来。如果团队有大半人用过Vue2，那就别强行上Vue3，等这个项目完了再慢慢迁移。我自己给这类系统搭建的时候，通常用Vue2加Element UI，整体风格简洁、组件齐全，和资源库后台管理的气质很搭。如果你能够完全掌控技术选型，Vue3加Element Plus也没毛病，性能更好、组合式API写起来更舒服。

工程结构方面，我习惯把视图和组件分开，目录大概是这样的：

• src/api：存放所有的接口请求方法，按模块拆分
• src/assets：静态资源
• src/components：通用组件
• src/router：路由配置
• src/store：全局状态
• src/views：页面级组件，按模块建子目录
• src/utils：工具方法，比如token存取、日期格式化

api目录是很多人容易忽略的点。我建议把每一个接口封装成一个方法，不要页面里到处写axios请求。比如resource.js里集中存getResourceList、getResourceDetail、uploadResource、favoriteResource这些方法，页面里只负责调用。这样后期接口一变，只需要改一个文件，而不是满项目里搜地址。这个习惯在我维护过的所有项目里都被证明是值得的。

Vue Router的路由配置也要注意区分权限路由。最简单的做法是：登录后根据当前用户的角色，在前端路由的meta字段里标注哪些页面仅教师和管理员可见，然后在路由守卫里判断。学生登录之后看不到上传资源和管理后台的入口，体验会清爽很多。

4.2 接口联调与跨域处理

前后端分离之后，联调最容易炸的就是跨域。本地开发时Vue跑在8080端口，后端跑在8081端口，直接请求必然跨域。解决方案很成熟：让前端脚手架代理请求。Vue CLI的vue.config.js里配置devServer.proxy，把/api开头的请求转发到后端地址，浏览器视角里请求就没有跨域问题了。这个方法比后端开启CORS的更顺滑，因为生产环境你还需要Nginx做反向代理，整个流程完全一致。

后端如果必须开CORS，也可以，但要注意不要无脑配置*，否则带上Authorization请求头的时候一样会被拦下来。正确做法是配置允许的源、允许的请求方法、允许的请求头，并且允许携带凭证。这些配置不复杂，但我见过太多人图省事只加一个CorsFilter，结果POST接口能通，加了token的GET接口照样报跨域。

axios的拦截器是联调时另一个关键点。响应拦截器里统一处理业务码：如果返回的code是200，直接返回data；如果是401，跳转登录页；如果是500，统一弹个错误提示。千万别每个页面都写一套错误处理，那样中后期维护会崩溃。我自己的习惯是除了拦截器之外，再封装一个统一的请求头注入逻辑，每次请求自动带上token，这样业务代码里完全不用关心鉴权这件事。

还有一个细节是上传进度和下载进度的处理，放在封装好的请求方法里统一配置。进度回调通过options参数传递，页面只要传onUploadProgress回来就能收到百分比。大视频上传的时候这个体验差异非常明显，强烈建议加上。

4.3 资源展示与在线预览的几种做法

教育教学资源库里最掉链子的功能往往是资源预览。上传了一个文档，结果用户下载下来才能看，体验确实不好。图片和视频的预览最简单：图片用标签渲染，视频用video标签，后端加个Range请求的支持，这些SSM配合Nginx默认就能做。但Office文档的在线预览就得分情况考虑了。

方案一：利用浏览器原生支持。PDF文件直接在浏览器新窗口打开，这个不需要后端做什么，因为现代浏览器都内置了PDF阅读器。方案二：图片、视频资源走后端静态映射，直接拼URL访问。方案三：Office文档的预览，如果只是内部使用，可以引入在线预览服务或者转换服务，把doc、docx转成PDF或者HTML再展示。这个转换过程比较重，第一版我不建议做，等核心功能稳定了再考虑。

大型视频文件在线预览时有两个容易踩的坑：一是Nginx默认不开启Range请求支持时，视频拖动进度条会失效，需要配置一下；二是内存溢出问题，如果后端用Java直接把整个视频读进内存再输出，并发一多直接OOM。解决方法是后端静态资源完全交给Nginx，Java不参与这种大文件IO，只负责签一个带token的链接，由Nginx直接响应文件内容。这也是我把文件存储和路径管理放在后端、把静态资源访问放在Nginx的原因。

还有一点容易被忽略：下载接口鉴权。如果一个资源下载链接直接暴露了文件路径，用户把链接四处传播，资源的访问控制就形同虚设。我在设计时通常会做一个“临时下载凭证”的接口：前端请求下载，后端校验权限之后生成一个短期有效的下载token，拼接在下载URL里；Nginx层或者一个转发接口再校验这个token，有效期内才允许访问文件。这个方案虽然多了一层，但能有效防止资源被爬虫和盗链，做教育类平台尤其值得注意。

5. 部署与运维的实战经验

5.1 后端打包与部署

SSM项目的部署方式很传统：Maven打成war包，放到Tomcat的webapps目录下，或者用Tomcat的管理界面部署。这里我提醒一个新手的坑：打war包之前先确认pom.xml里打包方式是war，并且排除掉测试代码，否则很容易把本地测试用的东西打进线上包。

如果是多环境部署，配置文件的切换要提前想好。我见过太多项目把数据库密码、文件上传路径这些写在applicationContext.xml里，结果每次换环境都要打开源码改配置，非常痛苦。建议把环境相关的配置单独拆到一个properties文件里，然后通过启动参数指定加载哪一份。比如数据库连接、上传目录、静态资源映射地址这些，都放在jdbc.properties和file.properties里，部署的时候直接改这两个文件就行，不用动代码。

Tomcat的配置也要调整几项：默认的POST数据大小是2MB，文件上传如果超过这个大小会直接被拒绝，需要在server.xml里配置maxPostSize。同时要给Tomcat设置合理的JVM内存参数，比如-Xms512m -Xmx1024m，否则并发上传大文件的时候很容易把堆内存占满。老项目常见的一启动就卡死，多半是内存参数没调。

前端打包就简单了，npm run build之后生成dist目录，然后把dist里的文件放到Nginx的根目录。Nginx需要配置两个关键location：一个是根路径/，指向前端静态文件目录；另一个是/api，反向代理到后端Tomcat地址。这里要注意前端的路由模式，如果用的history模式，还需要配置try_files，防止刷新页面的时候出现404。

5.2 数据库初始化与常用索引

数据库初始化脚本建议和代码一起放在版本管理里，不要靠人工去数据库里手工建表。一个init.sql文件，里面包含建库、建表、初始分类数据、初始管理员账号，新环境一小时就能跑起来。这个习惯对教学类项目尤其重要，因为交付的时候要给人家部署文档和脚本，没有初始化脚本的话交付体验会很差。

索引设计是资源库性能的关键。最常用的查询场景是“根据关键词和分类筛选资源”，所以t_resource表上至少要建这几个索引：分类ID索引、状态索引、创建时间索引。搜索关键词这块，如果只是简单的标题模糊搜索，用like ‘%keyword%’就好，数据量小的时候影响不大。等到数据量大了，可以考虑引入全文检索，但那是后话，第一版别过度设计。

MyBatis的Mapper写法上，建议所有列表查询都用PageHelper分页，不要手动写limit拼参数。PageHelper用起来虽然简单，但有一个容易被忽略的坑：它是在线程上下文中保存分页信息的，所以如果同一个线程里连续执行多条SQL，分页参数可能会错乱。解决方案是查询和分页插件调用尽量靠近，查询完尽快clearPage。这个细节我在一次联调时踩过，列表数据突然少了一部分，排查半天才发现是PageHelper影响了下一条SQL。

5.3 教学场景里的并发预期与安全底线

很多人觉得内部资源库并发量低，安全意识可以放松，这是个非常危险的想法。只要系统部署到公网，被人扫到端口、被人尝试SQL注入都是常规操作。后端的参数校验不能只依赖前端，所有SQL都要用预编译的#{}传参，不允许字符串拼接SQL。文件名和路径参数的校验更是重中之重，防止用户通过恶意构造文件名实施路径穿越。

上传接口必须做防刷限制。教学资源库里老师注册后就可以上传，如果不限制频率，恶意用户可能短时间内上传几百个垃圾文件把磁盘打爆。简单的做法是记录每个用户每天的上传次数和上传总大小，超过阈值就提示“今日上传额度已用完”。这个功能实现起来很简单，但对系统的保护价值非常大。

备份策略也不能省。第二天要上课，结果前一天的磁盘坏了，所有教案视频全丢，这种事故在机构里是灾难性的。建议每天凌晨自动备份数据库和一个tar的数据目录到异地目录，至少保留最近七天的备份。我见过一些小机构连数据库都不会配自动备份，系统跑了三个月出了故障才知道什么叫“欲哭无泪”。这些基础工作做在前面，后面能省下大量救火时间。

还有一个容易被忽略的点：管理员账号的初始密码一定要随机生成，并且强制第一次登录修改。默认admin/admin123这样的弱口令，在公网环境下基本上等于裸奔，扫描工具几分钟就能爆破出来。

教学资源库这类系统，本质上就是“资源进得来、出得去、管得住”。把文件存储、状态流转、权限控制这三条线理顺，整个项目就成功了一大半。SSM加Vue虽然不像新框架那样花哨，但胜在稳定可控，对教育行业这种追求稳妥的业务形态来说，反而是最合适的组合。如果你也在做类似的资源库，务必先把资源文件表拆出来，把审核状态机定好，再动手写代码，这样后面会顺畅很多。真遇到不好处理的细节，多想想“这个数据将来要怎么查、怎么展示、怎么统计”，答案基本就有了。