企业官网建设流程全解析

前阵子帮某高校信息中心做了一套学生实习综合服务平台，全程用 Vue3 做前端、Java 和 Spring Boot 搭后端，到现在系统已经稳定跑了两个实习周期。回想起来，这类系统最麻烦的从来不是某个接口怎么写，而是业务状态多、角色杂、数据链路长，稍微设计不到位，后面联调就是无底洞。这篇文章我就围绕“高校学生实习综合服务平台”这个标题，把整个项目的设计思路、技术选型、数据库建模、前后端实现细节和踩坑过程完整拆一遍，希望能给正在做类似管理系统、尤其是准备拿 Spring Boot 做毕设或者接手学校项目的同学一些参考。

文章内容主要适合三类人：准备做实习管理类系统的开发者、刚接触前后端分离架构想找完整案例的学生，以及需要给高校、培训机构落地信息管理平台但还没理清业务边界的项目经理。我会从需求梳理讲到部署排错，尽量把每一个设计决策背后的“为什么”也讲清楚，而不是只贴代码。

1. 项目整体定位与功能拆解

1.1 学生实习管理背后的真实痛点

做这类系统之前，一定要先搞清楚一个核心问题：高校实习管理的痛点到底在哪。很多人一上来就想着做 CRUD，学生发帖、企业看简历、随便点一下“录用”，看起来功能齐全，实际上连校内真实流程都覆盖不了。

我接触到的真实情况是：学生实习通常要经历找岗位、投简历、院系审批、企业确认、签协议、实习过程记录、周报月报、考核评估、学分认定这一长串环节。每一个环节都涉及不同角色——学生要填材料，辅导员要初审，院系教学秘书要复核，企业导师要反馈，教务管理员最后要归档。最痛苦的是这些信息分散在 Excel、微信群、教务系统甚至纸质材料里，根本没有一个统一的地方可以追踪进度。

所以这个平台的核心价值不是“发布岗位”，而是把实习全生命周期数字化，让所有角色在一个系统里完成协作。我设计的时候把整个系统定义为“以实习过程为主线、以审批流为核心、以数据统计为出口”的一体化平台，这样后面所有功能边界才能清晰。

1.2 用户角色与核心需求

平台我划分了四个核心角色，每个角色的诉求差异非常大：

除了这四个角色，我当时还把“教务管理员”并入了系统管理员里，避免角色过多、权限设计臃肿。在后期实现时，我会用 Spring Security 做 RBAC 权限模型，用一张角色表和一张用户-角色关联表承载这套关系，前端再配合动态路由把不同角色的菜单区分开。

1.3 功能模块全景图

整个平台功能模块我是这样拆的：

• 基础数据管理：学院、专业、班级、课程信息维护，这层数据是权限分配和统计报表的根基。
• 用户认证与权限模块：登录、登出、令牌刷新、密码重置、角色权限校验。
• 实习岗位管理：企业导师发布岗位、岗位上下架、审核流程、岗位收藏和检索。
• 实习申请与审批模块：学生提交申请、辅导员审核、院系管理员复核、企业确认，状态全程可追踪。
• 实习过程管理：签到打卡、周报提交、月报提交、企业导师在线评价。
• 实习总结与考核：学生上传实习总结报告，导师评分，院系最终认定学分。
• 数据统计看板：各院系实习率、岗位匹配度、周报提交率、单位满意度的图表统计和 Excel 导出。
• 系统管理：操作日志、字典管理、参数配置、消息通知。

这个功能列表看起来很长，但落到数据库也就十来张表。关键在于模块间的关系要理清：岗位表连接企业和学院，申请记录连接学生和岗位，实习记录连接申请和过程数据，这样从投递到结项的数据链路就是一条完整的线。

2. 技术栈选型与系统架构设计

2.1 为什么选 Spring Boot + Vue3

选型阶段我其实没有犹豫太久。后端用 Spring Boot 3.x 搭配 Java 17、Spring Security、MyBatis-Plus、MySQL 8、Redis，这套组合在高校管理系统里太成熟了，社区资料全、招聘需求大、遇到疑难问题容易搜到解决方案。

前端选择 Vue3 而不是 Vue2，核心原因是 Vue3 的组合式 API 对业务逻辑的复用能力比选项式 API 强太多。实习平台这种系统有很多重复的“列表 + 搜索 + 分页 + 弹窗表单”场景，用组合式函数可以把一套逻辑抽出来，不同页面直接复用。配合 TypeScript，代码的可维护性明显上一个台阶。UI 组件库用的是 Element Plus，目前 Vue3 生态里最稳的选择。

为什么不选微服务？这是很多学生容易犯的错——一上来就拆订单服务、用户服务、通知服务。这套系统的用户量级撑死几千人，部署在一台服务器上完全没问题，拆微服务只会让开发成本翻倍、问题排查变难。我最后采用的是模块化的单体架构：代码层面按业务模块分包，但部署时仍然是一个 Spring Boot 应用、一个前端静态包。

2.2 前后端分离架构下的请求流转

架构上我采用的是典型的前后端分离，数据流转大概是这样：

浏览器 -> Nginx 静态资源 -> Vue3 页面发起 Axios 请求 -> Nginx 反向代理转发到 Spring Boot 接口 -> Spring Security 认证与鉴权 -> Controller 接收参数 -> Service 处理业务 -> Mapper 操作数据库 -> 结果返回前端。

Nginx 在这个链路里承担了两件事：一是托管构建后的静态文件，二是把/api开头的请求反向代理到后端的8080端口。这样生产环境只有一个对外入口，避免跨域问题。开发阶段的前后端联调则通过 Vite 的 proxy 配置解决跨域，这个我在后面的实操部分详细说明。

2.3 后端工程结构与依赖清单

后端项目我用 Maven 管理，基础工程结构是这样：

com.example.internship ├── config // 配置类：Security、MybatisPlus、Redis、WebMvc ├── controller // 接口层，只做参数接收和结果封装 ├── service // 业务逻辑层，核心逻辑都在这里 │ └── impl ├── mapper // 数据访问层，MyBatis-Plus 的 BaseMapper ├── entity // 数据库实体类 ├── dto // 数据传输对象，避免实体直接暴露给前端 ├── vo // 视图对象，给前端返回定制化数据 ├── common // 公共类：统一返回结果、异常处理、常量 ├── util // 工具类：JWT、文件上传、导出 Excel └── InternshipApplication.java // 启动类

核心依赖我在pom.xml里配了这些：spring-boot-starter-web、spring-boot-starter-security、spring-boot-starter-validation、mybatis-plus-boot-starter 3.5.x、mysql-connector-j、spring-boot-starter-data-redis、jjwt 0.11.x、easyexcel、hutool。其中 hutool 是我强烈推荐的工具库，里面有日期处理、字符串工具、树形结构构建等一堆现成方法，写业务代码时能省大量时间。

2.4 前端工程与状态管理的规划

前端项目用 Vite 初始化，基础结构如下：

src ├── api // 按模块拆分的接口定义 ├── assets // 静态资源 ├── components // 公共组件：Upload、ExportButton、SearchForm 等 ├── composables // 组合式函数 ├── router // 路由配置，包含动态路由生成 ├── store // Pinia 状态管理 ├── views // 页面组件 ├── utils // 请求封装、权限指令等 └── main.ts

状态管理用的 Pinia。有些同学会用本地存储硬存用户信息，这种做法在小型系统里能跑，但刷新页面后状态恢复逻辑容易出问题。我这次的做法是：Pinia 里维护一个userStore，保存用户信息和权限码，刷新后通过一个getInfo接口重新拉取，再结合动态路由权限重新生成菜单。这个逻辑虽然多写几个文件，但用户体验和安全性都有保障。

3. 数据库建模：让岗位、申请、考勤数据不打架

3.1 核心表结构设计

数据库是整个系统的地基，地基歪了，后面写多少代码都是修补。我先说一下最重要的几张表。

学生信息表student_profile：字段包括user_id、student_no、name、gender、college_id、major_id、class_id、phone、resume_url、status。这里我把学生跟用户表通过user_id关联，而不是单独建一套账号密码。这样登录验证统一走用户表，学生档案只是补充信息。

实习岗位表internship_post：字段包括post_name、company_name、company_contact、post_desc、work_type、location、salary、need_num、applied_num、start_date、end_date、college_id、status。岗位为什么要有college_id？因为很多高校要求部分岗位只对指定学院开放，这相当于数据层面的过滤条件，比在接口里写死判断更清晰。

申请记录表application_record：字段包括student_id、post_id、status、apply_time、approve_time、college_approval、enterprise_approval、result。这张表是状态流转的主干，所有审批动作都围绕它展开。

实习记录表internship_record：一个学生最终可能只确认一条正式实习记录，所以它是申请记录的 1:1 或 N:1 延伸。字段包括application_id、contract_url、start_date、end_date、current_phase、mentor_id、overall_score、credit_status。

过程记录表：包括attendance_record和weekly_report。每周报告表的关键字段是internship_id、week_no、content、attachment_url、status、submit_time、feedback。过程数据全部挂在实习记录下，不要挂在申请记录下。

3.2 状态机设计：从申请到结项的状态流转

这是整个系统最核心的设计，我单独拿出来讲。实习申请的状态不能随便定义，必须画清楚状态流转图，否则一个“待审核”到底算院系审核还是企业审核，会乱套。

我在数据库里用整型数字表示状态，状态流转如下：

• 0 草稿：学生填写未提交。
• 1 待院系审核：学生提交申请，辅导员可查看。
• 2 院系通过 / 3 院系驳回：辅导员操作后进入对应状态。
• 4 待企业确认：院系通过后，企业导师确认是否接收。
• 5 已接收 / 6 已拒绝：企业导师操作。
• 7 实习中：企业和院系都确认通过后，自动进入实习中状态。
• 8 待总结：实习结束前两周，系统提醒提交总结报告。
• 9 已结项：导师评分、院系认定学分后完成闭环。
• 10 已终止：实习中途终止，需要填写终止原因。

这套状态机我在 Service 层通过一个状态流转校验方法控制，禁止跳状态操作。比如状态为“院系驳回”时，学生只能重新编辑并提交，不能直接跳到“待企业确认”。前端也会根据状态值控制操作按钮的显隐，比如状态是“待企业确认”时，学生端看不到“撤回”按钮。

3.3 多对多关系的数据落表

实习平台里多对多关系其实挺多：学生收藏岗位、学生选课导师、岗位绑定的技能标签。如果不在设计阶段理清这些关系，后面写 SQL 写到你怀疑人生。

拿“学生收藏岗位”这个需求举例：我建了一张favorite_record表，字段就三个：student_id、post_id、create_time，联合主键。不要嫌表多，一张只存关联关系的表反而是最清爽的。岗位技能标签同理，我用了post_tag_ref关联岗位表和标签字典表。

这里有一个实操建议：凡是关联表，都要在 Mapper 里加索引，student_id和post_id必须都建索引，否则随着业务量增长，查收藏记录会越来越慢。我实测一个十万行数据量的收藏表，没有联合索引时查询要 800ms 左右，加了索引直接降到 50ms 以内，效果非常明显。

4. 后端核心模块的实现细节

4.1 基于 JWT 的身份认证

认证方案我选的是 JWT 搭配 Redis。登录成功后后端生成一个 token，并把这个 token 作为 key 存到 Redis 里，value 是用户基础信息 JSON。后续每次请求，前端在 Authorization 头带上 token，后端通过一个过滤器解析 token、校验 Redis 里的会话是否存在、刷新过期时间。

使用 Redis 管理用户会话有一个容易被忽略的好处：可以实现主动下线和管理员踢人。管理员发现某个账号异常后，直接删除 Redis 里的 token 记录，该用户下一次请求就会被拦截。如果只用纯 JWT 无状态方案，这种操作根本做不到。

核心认证过滤器代码如下：

@Component public class JwtAuthenticationFilter extends OncePerRequestFilter { private final JwtTokenProvider jwtTokenProvider; private final UserDetailsService userDetailsService; @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String token = resolveToken(request); if (token != null && jwtTokenProvider.validateToken(token)) { String username = jwtTokenProvider.getUsernameFromToken(token); UserDetails userDetails = userDetailsService.loadUserByUsername(username); UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities()); authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(request)); SecurityContextHolder.getContext().setAuthentication(authentication); } chain.doFilter(request, response); } }

这套代码有两个点容易出错：一是过滤器在 Spring Security 过滤器链里的顺序要放在UsernamePasswordAuthenticationFilter之前，否则认证会先走表单登录逻辑；二是validateToken里除了校验签名，还要检查 Redis 中是否存在这个 key，防止已注销的用户拿旧 token 继续访问。

4.2 岗位申请与审批流程控制

审批流程的后端实现，我采用的是“状态判断 + 操作日志”双重机制。每一次状态变更，不只是 update 一条记录，还要往operation_log表插一条日志，记录操作人、操作时间、操作前状态、操作后状态、备注。这样做的好处一是责任可追溯，二是前端可以展示完整的审批轨迹时间线。

关键实现思想是审批动作拆成独立接口，而不是一个接口传 type 参数判断不同动作。比如院系审核就是POST /api/application/{id}/college-approve，企业确认就是POST /api/application/{id}/enterprise-confirm。这样做虽然接口数量多一点，但每个接口的参数简单、校验逻辑清晰，权限注解也能精确控制到角色。

以下是院系审核的核心逻辑：

@Override @Transactional(rollbackFor = Exception.class) public void collegeApprove(Long applicationId, Boolean approved, String comment) { ApplicationRecord record = applicationRecordMapper.selectById(applicationId); if (record == null || record.getStatus() != 1) { throw new BusinessException("当前状态不可执行院系审核操作"); } int newStatus = approved ? 4 : 3; record.setStatus(newStatus); record.setCollegeComment(comment); record.setApproveTime(LocalDateTime.now()); applicationRecordMapper.updateById(record); operationLogService.record(applicationId, "college_approve", approved ? "院系审核通过" : "院系审核驳回", comment); if (approved) { notificationService.sendToEnterprise(record.getPostId(), "有新的实习申请待确认"); } else { notificationService.sendToStudent(record.getStudentId(), "院系审核未通过，请查看原因并及时修改"); } }

这里我用@Transactional保证状态更新和日志插入同生共死，避免出现状态改了但日志没记录的脏数据。状态校验我放在 Service 层做，而不是依赖前端隐藏按钮，因为接口可以被直接调用，后端永远不能信任前端传过来的状态。

4.3 实习过程的签到、周报、月报

实习过程管理看似简单，其实涉及大量时间判断。比如周报提交，要判断当前是否在实习周期内、是否超过最晚提交时间、周次编号怎么计算，这些逻辑一点都不能拍脑袋写。

每周报的周次计算，我通过实习开始日期和当前日期推算。具体做法是：实习记录创建时，把实习周期按周拆好，存到一张internship_schedule表里，每周的记录包含week_no、week_start、week_end、submit_deadline、status。周报提交时，后端先查当前日期落在哪一个week_no，然后校验该周状态是否为“未提交”，同时判断当前时间是否超过submit_deadline。实测下来这样设计非常稳，比每次动态计算省心太多，也方便未来做补交、超时标记。

考勤签到我做了“地理位置 + 时间窗口”双重校验。学生签到时，后端接收经纬度，通过 Haversine 公式计算与实习单位定位的距离，超过 500 米就报错。这里要提醒：真实项目里别把距离限制写死成 50 米，因为 GPS 定位在室内偏移很严重，实测下来 200 米到 500 米之间比较合理。

4.4 数据统计与 Excel 导出

统计模块我用了两种方式渐进实现：核心看板指标用聚合 SQL 直接查询，多维分析用 EasyExcel 导出。先说前者，统计各学院实习率的核心 SQL 大概是这样的：

<select id="selectCollegeInternshipStats" resultType="map"> SELECT c.college_name AS collegeName, COUNT(DISTINCT s.id) AS totalStudents, COUNT(DISTINCT ir.student_id) AS internedStudents, IFNULL(ROUND(COUNT(DISTINCT ir.student_id) / COUNT(DISTINCT s.id) * 100, 2), 0) AS rate FROM college c LEFT JOIN student_profile s ON s.college_id = c.id LEFT JOIN internship_record ir ON ir.student_id = s.id AND ir.status IN (7, 9) GROUP BY c.id, c.college_name ORDER BY rate DESC </select>

Excel 导出这块，EasyExcel 的优势是低内存占用。导出时我用asyncService.execute()把导出任务丢到线程池，前端轮询导出状态，完成后下载。千万不能直接同步导出，表数据一旦上到几万行，同步导出会让请求超时。

5. 前端 Vue3 的落地实现

5.1 组合式 API 组织业务逻辑

Vue3 组合式 API 让我最受益的一点是，业务复用真的可以被“抽出来”。实习平台高频场景就是“列表 + 查询条件 + 分页”，我封装了一个usePage组合式函数，把分页逻辑、加载状态、列表数据都收在一起：

export function usePage<T>(apiFunc: (params: any) => Promise<PageResult<T>>, initialParams = {}) { const list = ref<T[]>([]); const loading = ref(false); const total = ref(0); const queryParams = reactive({ page: 1, pageSize: 10, ...initialParams }); async function fetchList() { loading.value = true; try { const res = await apiFunc(queryParams); list.value = res.records; total.value = res.total; } finally { loading.value = false; } } function handleSearch() { queryParams.page = 1; fetchList(); } function handlePageChange(page: number) { queryParams.page = page; fetchList(); } return { list, loading, total, queryParams, fetchList, handleSearch, handlePageChange }; }

用的时候不同页面只要调用const { list, loading, ... } = usePage(fetchApplications)就行。这个习惯让我的代码量大幅减少，每个页面不再重复写 loading、捕获错误、重置页码这些样板逻辑。

5.2 动态路由与菜单权限

实习平台不同角色看到的菜单完全不同，所以我把路由表拆成了两部分：静态路由和动态路由。静态路由只有登录页、404 页；动态路由在用户登录后，前端拿到后端返回的权限码数组，遍历一个路由映射表，把符合权限的组件动态添加进去。

后端返回给前端的权限码是根据角色查询出来的。比如学生角色返回["student:post:list", "student:application:submit"]，企业导师返回["enterprise:post:create", "enterprise:application:review"]。前端通过一个权限指令控制按钮级显示：

app.directive('perm', { mounted(el, binding) { const userStore = useUserStore(); const required = binding.value; if (required && !userStore.permissions.includes(required)) { el.parentNode?.removeChild(el); } } });

这种权限设计说起来简单，但落地时要特别注意一个问题：按钮隐藏只是体验优化，真正的安全校验永远在后端接口上。前端隐藏了按钮，用户照样可以通过 Postman 调接口，所以后端每个接口都要有对应的权限注解。

5.3 审批工作流的交互设计

审批流程的前端体验，我花了不少心思在“轨迹展示”上。学生提交申请后，最想知道的就是“现在卡在谁那里”。我实现了一个横向步骤条组件，用 Element Plus 的el-steps展示院系审核、企业确认、开始实习、结项评估四个阶段，当前阶段高亮。

但这里有两个交互细节是文档里不会写的：

第一，el-steps的每个步骤状态不能直接写死在数据里，要根据后端返回的状态字段动态计算。我写了个辅助函数，把后端状态码映射成步骤索引和状态值。第二，审批被驳回后，步骤条不能简单显示一个失败态，要能展示驳回原因和修改入口，否则学生只能干看着不知道要改哪里。

我还做了一个消息铃铛组件，配合后端的 WebSocket 通知，每当审批状态变化，前端即时弹出提醒。这个功能实现不复杂，后端在状态变更后通过 WebSocket 往指定用户频道推送一条消息，前端监听消息后在铃铛上显示未读数量。

5.4 文件上传与预览的通用方案

实习平台涉及大量文件上传：简历 PDF、实习协议照片、周报附件、总结报告。如果每个模块单独写上传逻辑，不仅代码重复，后期维护还容易漏。我统一做了一个 UploadFile 组件，封装了 el-upload 上传、进度条、校验文件类型和大小、上传成功后回调等逻辑。

上传后端实现我封了一个handleFileUpload通用接口，用 OSS 还是本地存储看项目条件。我这次做的是本地存储，Nginx 配置了一个虚拟目录把/files/**映射到服务器上的上传目录，前端通过baseUrl + 文件相对路径直接预览。

文件上传有个安全知识点——文件名必须重新生成，不能沿用用户原始文件名。我用的是一个 UUID 拼接扩展名，扩展名做了白名单校验，只允许 jpg、png、pdf、doc、docx 这几种。不这样做的话，用户上传一个后缀为 jsp 的文件并直接访问，服务器就有被攻击的风险。

6. 部署测试与常见问题排查

6.1 打包部署注意事项

本地开发完成后，部署我按以下流程操作，中间踩过两个坑，后面细说：

第一步，后端执行mvn clean package -DskipTests打出 jar 包，通过java -jar启动。Spring Boot 内嵌了 Tomcat，所以不需要额外装 Tomcat。

第二步，前端执行npm run build构建静态文件，产物在dist目录，把这个目录上传到服务器 Nginx 的 html 目录下。

第三步，配置 Nginx 反向代理，关键配置如下：

server { listen 80; server_name your-domain.com; # 前端静态资源 location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } # 后端接口代理 location /api/ { proxy_pass http://127.0.0.1:8080/api/; 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 /files/ { alias /data/internship/files/; } }

这里的try_files必须配置，否则 Vue Router 用 history 模式时，刷新页面会直接 404，这是前端部署最常见的坑。

6.2 高频问题实录

我挑三个实际项目中出现频率最高的问题，每个都值得提前预防：

问题一：跨域访问失败。开发环境下 Vite 通过 proxy 能解决，部署后如果走 Nginx 同域反向代理基本不会跨域。但有种情况很容易忽略：如果后端接口里写了 CORS 配置类，同时 Nginx 又做了跨域处理，双重跨域配置会冲突，导致请求多一次 OPTIONS 预检。解决办法是二选一，我推荐生产环境用 Nginx 做掉所有跨域逻辑，后端不用再加 CORS 配置。

问题二：时间字段相差 8 小时。MySQL 的datetime与时区设置、Java 端的LocalDateTime序列化配置层层叠加，会出现存储时间和前端显示时间不一致的现象。我统一在 Spring Boot 配置里设置了spring.jackson.time-zone=GMT+8，MySQL 连接串追加serverTimezone=Asia/Shanghai，前端再统一用 dayjs 做格式化，三端一致后这个问题就没再出现过。

问题三：MyBatis-Plus 分页查总数慢。当查询条件特别复杂时，分页插件会先执行一次 count 查询，这个 count 可能会慢到几百毫秒。解决办法是给高频查询涉及的字段建组合索引，另外把optimizeCountSql保持默认开启状态，它会在满足条件时自动去掉 order by，减少不必要开销。

7. 复盘：实际开发中最容易踩的坑

最后聊几个我做完这套平台总结出来的独家经验。这些东西通常不会写在教科书里，但遇到一次能让人难受好几天。

第一，不要低估数据权限的重要性。一开始我以为只要做好菜单权限就够了，后来院系管理员提需求说“我只能看到本院系学生的实习数据”，我才发现接口里到处需要拼接学院条件。我的解决方案是封装了一个DataScopeHelper，在 Service 层取出当前登录用户的学院 ID，统一拼装到查询条件里。所有列表查询接口都要支持类似collegeId的隐形过滤，这个设计越早做越好，后期补会很痛苦。

第二，审批操作必须保证幂等性。前端网络重试、用户双击提交按钮，都可能导致同一个审批请求发两次。如果后端没有做幂等控制，就会产生两条状态变更日志。我的做法是在application_record表加一个process_version字段，更新时用UPDATE ... WHERE id = ? AND process_version = ?做乐观锁，更新成功后版本号加一。第二次请求带旧版本号，影响行数为 0，直接拒绝。

第三，消息通知要及时触发，但不能阻塞主流程。实习平台里，企业确认一个申请、院系驳回一个申请，都需要发站内信甚至短信通知。我第一次实现时直接在业务方法里同步发短信，结果短信通道超时，整个审批接口也超时了。后来我把通知逻辑全部改成发送到 Redis 消息队列，由异步消费者处理，这样短信网关再怎么慢，也不影响主流程响应。

第四，前端不要过度封装。这一点算是经验教训。开发过程中我一度想把所有表单封装成一个通用组件，结果配置项越来越多，到最后改一个字段要比直接写原生表单还麻烦。第二版我调整策略：只封装高频且结构稳定的场景，比如列表页的搜索栏和分页条，复杂表单老老实实写。代码看起来重复一点，但每个页面都独立可改，团队沟通成本低很多。

说回这个平台本身，其实技术上没有哪个点是“非它不可”的，但把这些模块用合理的架构串起来，让业务跑顺、让角色不互相干扰，才是项目真正的价值所在。我个人的体会是，做管理系统切忌堆功能，一定要先把业务状态理清。状态机一乱，后面所有审批、统计、权限都会跟着乱。你如果正准备做类似的项目，不妨先在纸上把角色、操作、状态流转画清楚，再动代码，后面省下来的时间绝对值得。