企业官网建设流程全解析

前后端分离的管理系统这几年我做下来不下十来个，但拿到“乡村养老服务管理系统”这个题目的时候，还是觉得有点东西可以聊。它不是那种纯增删改查的玩具项目，也不是大厂那种动不动就上微服务的庞然大物，而是一个典型的、把真实业务和技术栈结合得比较紧的中小型管理系统。Spring Boot + Vue + MySQL 这套组合，基本是 Java 全栈开发者的入门标配，也是很多课程设计、毕业设计和中小型商用项目的首选方案。它的价值在于：麻雀虽小五脏俱全，从用户登录认证、权限控制、数据关联查询，到前端路由守卫、组件通信、图表展示，再到最后的打包部署、线上调试，一整条链路全都能跑通。这篇文章我不打算照着 README 念，而是把一个乡村养老项目从需求拆解、表结构设计、后端接口实现、前端页面落地，到部署排坑的完整思路掰开揉碎讲清楚。

先给这篇文章定个位。适合三类人看：第一类是正在做 Spring Boot + Vue 课设或毕设的在校学生，需要一个能讲清楚、能通过答辩的完整项目做参考；第二类是刚入职、想通过一个真实业务项目补齐前后端协作经验的新人；第三类是确实要给村级或社区做养老服务信息化的开发者，想看看这类系统通常怎么规划。当然，无论你属于哪一类，看完之后至少能获得三样东西：一套可以直接落地的数据库设计思路，一套前后端接口约定的标准做法，还有一份从开发到部署的完整避坑清单。

1. 乡村养老服务，到底需要系统管什么

1.1 业务场景的真实痛点

乡村养老和城市养老最大的区别在于资源密度和信息化基础。城市里有社区服务中心、养老驿站、专业护理机构，信息流转相对顺畅；乡村往往是分散居住、服务人手不足、老年人健康数据靠纸质台账，家属常年在外务工，老人身体状况和生活需求很难实时掌握。村级干部或民政专员日常要处理的杂事非常多：谁家的老人需要上门送餐、谁这个月还没做健康随访、哪位老人的降压药快吃完了、志愿者今天去的是哪几户，这些信息如果没有一个统一的系统去承载，很容易漏掉或者重复劳动。

我在设计这类系统时，第一件事不是打开 IDE 写代码，而是先把人、事、物之间的关系理清楚。人包括老人、家属、村务工作者、志愿者、卫生室医生；事包括送餐、探访、健康巡检、活动组织、工单派发；物包括健康档案、服务记录、活动记录、通知公告。把这些业务实体和动作拆出来之后，你会发现它本质上是一个带有业务流转性质的信息管理系统：有人录入数据，有人处理服务请求，有人查看统计结果，不同角色各管一段。

1.2 功能需求如何转化为系统模块

在这个项目里，我最终把功能划分成五大块：老人档案管理、服务工单闭环、健康数据追踪、活动与公告发布、系统权限控制。每一块都有明确的业务出口。

老人档案管理是基础中的基础，核心不仅仅是姓名、身份证号、联系电话这些静态字段，更要有子女联系方式、居住地址、紧急联系人、生活自理能力评估、既往病史标签、当前用药情况。这些信息直接决定后续服务派单的优先级和内容。服务工单模块承担业务流，志愿者登录后能查看待办任务，完成任务后填写服务记录，村务工作者可以对工单进行审核和归档。健康数据追踪则负责把老人的血压、血糖、心率等体征数据按时间维度存储，前端用折线图展示变化趋势，方便卫生室医生做慢病干预。活动与公告模块解决信息触达的问题，村里组织义诊或者节日慰问，系统可以提前通知到相关人员。系统管理模块做的就是用户、角色、菜单权限这些东西。

1.3 非功能性需求的现实约束

除了业务功能，这类系统在实际落地时还要考虑几个现实约束。第一是网络环境，部分乡村网络基础设施并不理想，所以系统要尽量轻量，页面加载速度要快，接口响应要稳。第二是使用者的技术水平，很多村级工作人员对系统的接受度有限，页面交互必须足够简单直接，表单不能太复杂，按钮名称要符合日常用语习惯。第三是成本，乡村级项目预算普遍不高，所以技术栈必须选成熟、免费、社区活跃的方案，这就决定了 Spring Boot + Vue + MySQL 这套几乎零成本的组合是合适的选择。

2. 技术选型不只是选框架，关键看组合逻辑

2.1 为什么是 Spring Boot 而不是 SSM 或者 Spring Cloud

现在很多教材还在教 SSM（Spring + Spring MVC + MyBatis），但实际操作中 Spring Boot 已经成为绝对主流，尤其是中小型项目。它的价值不在于“新”，而在于把大量配置自动完成，让我们少写一堆 XML。Spring Boot 内嵌 Tomcat 意味着打出一个 jar 包就能直接跑，不需要在服务器上单独装 Servlet 容器，这对部署环境不稳定的乡村项目来说极为友好。同时，它的 starter 机制让集成 MyBatis、MySQL、Redis、JWT 等组件变得极其简单，只是引入一个依赖、写几行配置就能用。

为什么不用 Spring Cloud？因为业务复杂度根本到不了微服务的级别。微服务解决的是团队协作和弹性伸缩的问题，代价是分布式事务、服务治理、链路追踪这些额外的复杂度。一个面向村级业务的管理系统，单机部署完全够用，强行拆微服务只会给自己找麻烦。这个项目的规模对应的人数、数据和并发量，单体应用加上合理的缓存策略就能轻松扛住。

如果你的项目是用 Spring Boot 的，那我强烈建议直接用 Spring Initializr 创建，把 Web、MyBatis、MySQL Driver、Validation 这几个起步依赖勾上。Lombok 也可以加，能省掉大量 getter/setter 的代码冗余，但要注意让团队成员都用同一版本，避免 IDE 编译问题。

2.2 Vue 前端在什么场景下比 JSP 更合适

过去做 Java Web 项目常用 JSP，但这种方案在前后端分离的大环境下已经显得很笨重。JSP 的痛点在于页面逻辑和后端渲染耦合，改个页面样式要重启服务，前后端没法并行开发。Vue 的组件化开发方式对这类系统的适配度非常高。

拿本项目的页面结构来说，左侧菜单、顶部导航、中间内容区就是一个典型布局，用 Vue Router 配置几个路由嵌套就能搞定。老人列表、服务工单、健康图表这些页面各自封装成组件，数据通过 Axios 请求后端接口获取，状态用 Vuex 或 Pinia 管理。组件化的好处是每个页面独立维护，改列表页的样式不会影响表单页的交互，这对后期迭代非常重要。

Vue 2 和 Vue 3 的选择上，新项目建议直接从 Vue 3 起步。Vue 3 的组合式 API（Composition API）对逻辑复用确实比选项式 API 更顺手，而且生态已经非常成熟。配套 UI 组件库选择 Element Plus，它对后台管理系统的覆盖面很全：表格、表单、弹窗、分页、上传、日期选择这些现成组件，改改属性就能用，开发效率会快很多。

2.3 MySQL 为什么够用，以及如何规划数据库

数据存储层面，MySQL 8.0 是目前比较稳妥的选择。养老管理系统的数据模型完全是关系型的，老人、工单、健康记录之间都存在明确的关联关系，用关系型数据库管理这类数据，事务一致性、联表查询和权限控制都有很成熟的方案。有人可能会提 MongoDB，但它的优势在于灵活文档模型，在没有强烈非结构化存储需求时，MySQL 的生态和运维便利性要强得多。最关键的是，MySQL 对服务器资源的要求很低，一个 2 核 4G 的云主机跑起来绰绰有余。

数据库命名方面，建议用统一的规范，数据库名用elderly_care，表名用sys_前缀表示系统表，elder_前缀表示业务表。字段类型也要想清楚：年龄用 int，精确到日的日期用 date，带时间的用 datetime，金额用 decimal(10,2)，性别、状态这类固定枚举用 tinyint，文本说明用 varchar，长文本用 text。这些都是很小的细节，但确定好规范后写代码会省很多事。

3. 数据库设计是系统的骨架，这一步不能偷懒

3.1 核心表结构拆解

我直接说核心的表以及它们之间的关系。

老人表elder_info，存储老人的基础档案信息。字段包括：主键 id、姓名、性别、身份证号、出生日期、联系电话、居住地址、所属网格/村组、健康状况标签、自理能力等级、子女姓名、子女联系方式、入住状态等。这里一个容易被忽略的点是“入住状态”，乡村养老不一定都是机构入住，更多是居家养老和社区日间照料，所以这个字段要区分：居家、日间照料、机构入住。不同状态下服务的分配策略完全不同。

家属信息看似冗余，但它非常重要。乡村老人很多不用智能手机，联系不上老人本人的时候，必须能快速联系到子女或紧急联系人。我的做法是单独抽一张elder_family表，支持一个老人关联多个家属，同时标注关系类型和是否紧急联系人。

服务工单表service_order是业务流转的核心。字段包括：工单编号、老人 ID、服务类型、服务内容描述、分配的服务人员 ID、工单状态、创建人、创建时间、接单时间、完成时间、服务评价、评价备注。工单状态我用整数表示：0 待分配、1 待服务、2 服务中、3 已完成、4 已取消。状态流转是这类系统的核心逻辑，待分配可以由管理员指派给服务人员，服务人员接单后变为待服务，签到开始后是服务中，提交服务记录后变为已完成。

健康记录表elder_health_record，记录每次测量或随访得到的体征数据。字段包括：老人 ID、测量时间、血压收缩压、血压舒张压、心率、血糖、体温、身高体重、备注。注意这里不要存“正常”或“异常”这种主观判断，只存原始数据和测量条件，判断逻辑交给前端或者分析服务，这样数据更有复用价值。

系统表部分包括用户表sys_user、角色表sys_role、菜单表sys_menu、用户角色关联表、角色菜单关联表。用户表存储账号、密码、姓名、手机号、所属角色等。密码存储禁用明文，我用 BCrypt 加密，注册和登录时的密码验证都用 BCrypt 的校验方法。

3.2 表关联与索引设计

表关系逻辑比较简单：老人和健康记录是一对多，老人和工单是一对多，用户和角色是多对多（一个用户允许有多个角色，比如既是管理员又是服务人员），角色和菜单也是多对多（控制不同角色能看到哪些页面和功能按钮）。

索引设计往往是新手最容易忽略的地方。我的建议是：外键字段必须建索引，比如elder_health_record表里的elder_id，service_order表里的elder_id和assignee_id；状态字段也要建索引，因为业务上会经常按状态过滤；时间字段按需建索引，但要注意范围查询用不到索引的情况。不需要为所有字段都建索引，索引不是越多越好，它会拖慢写入速度。

初始化数据也很重要。管理员账号、角色、菜单、字典数据、基础配置，这些应该在项目交付时提供一份 SQL 初始化脚本，避免部署者手动去填。我在交付项目时通常把 SQL 拆成两个文件：schema.sql负责建表，data.sql负责插入基础数据，这样可以避免反复执行时重复插入。

4. 后端接口设计与核心代码实现

4.1 统一返回格式与异常处理

前后端分离项目中，接口设计的第一件事不是写 Controller，而是定义一套统一的返回格式。我在这个项目里用的是Result<T>泛型类，结构包含三个字段：code 状态码、msg 提示信息、data 数据主体。成功时 code 为 200，业务异常时 code 可以是 500 或 400，未登录时 code 为 401，无权限时 code 为 403。这样的好处是前端 Axios 拦截器可以统一处理返回结果，不需要每个请求都单独判断。

对应的异常处理用@RestControllerAdvice全局拦截。业务异常可以自定义一个BusinessException，里面持有一个错误码和消息，这样在 Service 层遇到业务不满足的情况直接抛异常，由全局处理器统一组装返回。统一处理之后，Controller 代码可以保持极度的简洁，只负责接收参数和调用 Service，业务逻辑全部下沉。

4.2 认证与权限控制的落地

管理系统的认证方案，我选择了 JWT + Spring Security 的组合。用户登录成功后，后端根据用户 ID、角色、过期时间生成签名后的 Token 返回给前端，前端在每次请求的 Headers 里带上Authorization: Bearer <token>，后端过滤器解析 Token 并设置当前登录用户上下文。

Spring Security 的配置并不复杂，关键点在于自定义UserDetailsService从数据库查询用户，以及放行登录接口，其余接口都要认证。权限控制上，用@PreAuthorize("hasRole('ADMIN')")这类注解可以做到方法级控制。比如老人档案的删除操作只允许管理员，服务人员只能更新分配给自己的工单。

需要注意的一点是 JWT 的密钥和过期时间不要写死在代码里，放到application.yml中配置。生产环境密钥必须足够长，且定期更换。Token 过期时间一般不要超过 24 小时，我习惯设为 12 小时，再配合前端在 401 时自动跳转登录页。

4.3 业务接口的典型实现：以服务工单为例

我用服务工单的“分配-接单-完成”流程来说明后端接口的写法。

创建工单时，前端提交表单数据，包括老人 ID、服务类型、服务内容、期望服务时间。后端 Controller 接收 DTO，做参数校验后，调用 Service 的createOrder方法。Service 内部会做几件事：检查老人是否存在，检查该老人是否有未完成的同类型工单（避免重复派单），生成工单编号（我用时间戳 + 随机数），保存订单并初始化为待分配状态。

分配工单时，管理员选择一个服务人员，修改工单状态为待服务。这里要考虑的边界情况是：工单在被分配之前如果已经超过预定服务时间，系统允许管理员取消。这就是状态机的价值，代码不会出现状态乱跳。

服务人员接单后，状态变为服务中。完成服务时，服务人员提交服务记录和现场拍照，系统将状态置为已完成，并记录完成时间。这个流程的每一步都对应一次数据更新，由于工单状态变更频繁，状态字段尽量用整数枚举，不要用字符串，这样数据库存储和比较都更快。

4.4 多条件组合查询与分页实现

管理系统里躲不开的场景就是列表的多条件组合查询，比如老人列表要支持按姓名、村组、健康标签、自理能力等级筛选，要支持分页。我采用 MyBatis-Plus 的方式，构造LambdaQueryWrapper动态拼条件，配合分页插件PaginationInnerInterceptor，前端传 pageNum 和 pageSize 参数，后端返回IPage<T>对象，里面包含记录列表、总数、当前页、总页数。

这里的核心技巧是：前端传过来的筛选条件不是固定不变的，所以代码里不能写死 where 条件，而是要根据参数是否为 null 来动态决定是否拼接到查询中。MyBatis-Plus 的eq和like方法天然支持这种写法。条件值为空时就不拼，这样页面刷新后可以不携带任何参数，默认查询全部。

需要注意 SQL 注入问题。使用 MyBatis-Plus 构造器，参数值会被预编译绑定，所以不用过度担心注入。但如果是纯手写 XML SQL，拼接条件时必须用#{}而不是${}，这点非常重要。

4.5 文件上传：老人照片与服务现场照片

乡村养老系统中，上传场景主要有老人证件照片、服务现场照片、活动宣传图。我采用的方案是上传文件保存到服务器本地磁盘，然后把文件访问的虚拟路径映射到静态资源目录。前端用 Element Plus 的 Upload 组件，设置 action 为后端的/api/file/upload接口，上传成功后返回文件 URL，再把这个 URL 组合进业务表单提交。

磁盘存储方案比对象存储更适合这种中小型项目，因为操作简单且不依赖外部服务。但要注意保存路径的规划，我使用yyyy/MM/dd目录结构，加上 UUID 重命名文件，这样可以避免文件名冲突和目录文件过多导致查找慢。同时在后端定义文件大小上限，图片限制在 5MB 内，避免大文件拖垮服务器带宽。

5. 前端页面与交互实现要点

5.1 路由与布局设计

前端部分我使用了 Vue Router 配置路由表，整体布局是左侧菜单 + 顶部导航 + 内容区域。路由配置里有一个核心技巧：通过路由守卫做登录判断，所有页面都要求先登录才能访问，未登录的用户统一跳转到登录页。另一个是动态路由，根据用户角色动态生成可访问的菜单和路由，这一步配合后端的菜单权限数据来实现。

动态路由的实现思路是：后端提供一个菜单树接口，根据当前用户角色返回他能看到的菜单列表，前端拿到数据后用router.addRoute动态注册路由。这样不同角色登录后将看到完全不同的页面，管理员的菜单包含系统管理，服务人员则只看到自己的工单、老人列表和健康记录。

5.2 表格页的封装与复用

老人列表、工单列表、健康记录列表这些页面的结构高度相似，都是顶部筛选条件、中间表格、底部翻页、右侧操作按钮。为了减少重复代码，我把这个结构封装成一个通用列表组件，通过 props 传入表格列配置、请求方法、筛选表单配置，每次只需要写配置就能生成一个新页面。

表格操作按钮的处理也是一个细节。比如老人列表里，每行有查看、编辑、删除按钮。删除操作必须二次确认，我通过 Element Plus 的确认弹窗组件实现。操作完成之后刷新表格数据，刷新时保持当前页不变，不要跳回第一页，避免操作员翻页体验的断裂。

5.3 健康数据的可视化

健康数据展示是本项目比较出彩的部分。使用 ECharts 的折线图展示某个老人的血压趋势、血糖趋势。ECharts 在 Vue 里的用法是：初始化一个 div 容器，setOption 传入数据，然后响应式地更新数据。

我提供一个建议：不要在前端写死图表的高度，用百分比让图表自适应容器。ECharts 在容器大小变化时不会自动重绘，需要在窗口 resize 时调用chart.resize()方法，否则会出现图表嵌在页面中不变形的问题。如果你的页面中图表数量较多，建议使用一个封装好的图表组件，统一处理初始化和销毁逻辑。

5.4 状态与数据的实时更新

养老服务是强交互场景，工单状态变化频繁，单纯靠手动刷新的体验比较差。我的实现方案是短轮询 + 接口缓存。比如工单列表页面，每 30 秒请求一次待办数量接口，在导航栏上显示小红点或数量角标，提醒服务人员有新的待办任务。这个方案对服务器的压力极小，但用户体验的改善非常明显。不需要上 WebSocket 或者 SSE，因为实时性要求没那么高，短轮询完全够用，而且实现和维护成本低很多。

6. 部署调试到大文档交付，项目完整落地的最后一公里

6.1 本地开发环境的统一构建

项目交付时，最忌讳的是部署文档写得含糊不清，接手的人装半天环境也跑不起来。我的做法是提供三份环境准备说明：后端 JDK 17 + Maven 3.8+，前端 Node.js 16+，数据库 MySQL 8.0。开发工具不强求，IDEA 和 VSCode 是最常见的组合。

后端启动前需要改动的配置集中在application.yml：数据库连接地址、端口、JWT 密钥、文件上传目录。前端启动前要确认.env.development里的接口基础路径，通常配成代理方式VITE_PROXY_TARGET指向http://localhost:8080，由 Vite 的 proxy 配置解决跨域问题，开发环境避免使用 Nginx 转发。

数据库初始化是新手最容易卡住的地方。我建议用命令行导入而不是直接复制粘贴到数据库工具执行，因为 SQL 文件大时工具容易假死。执行顺序是：先建库CREATE DATABASE elderly_care DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;，然后USE elderly_care;，最后SOURCE /path/to/schema.sql;和SOURCE /path/to/data.sql;。

6.2 生产环境部署的关键步骤

生产部署我采用最经典的两件套方案：后端 jar 包 + Nginx 静态页面。前端打包时会生成 dist 目录，里面是纯静态文件，复制到服务器的/var/www/elderly-care目录下。Nginx 的配置比较关键，有三块内容：

第一个是静态资源服务，root指向 dist 目录，try_files $uri $uri/ /index.html处理 Vue Router 的 history 模式，否则直接刷新非首页路由会 404。第二个是反向代理，所有/api开头的请求都要转发到后端服务，proxy_pass http://127.0.0.1:8080;。第三个是 gzip 压缩，开启后静态资源的传输体积能减少 60% 以上，对网络条件一般的乡村带宽来说很管用。

后端部署要把 jar 包放到服务器目录，用nohup java -jar elderly-care.jar --spring.profiles.active=prod &启动。线上环境建议把 JVM 参数带上，比如-Xms256m -Xmx512m，这可以避免服务因内存波动被系统杀掉。如果需要开机自启，写一个 systemd service 文件挂上就行。日志输出用-Dlogging.file.path指定日志目录，排查问题全靠它。

6.3 大文档编写与讲解视频的配套思路

项目交付物里如果有“大文档”和“讲解”，那说明认真做项目的同学还关心一个问题：答辩或者交接时，别人怎么能快速理解这个系统。一套好的项目文档通常包含六章：需求分析、系统设计、数据库设计、核心代码讲解、部署手册、测试报告。每章不能只是贴代码和截图，要有因果链条。比如“为什么工单状态是整数而不是字符串”，回答是“数据库存储更紧凑、比对更快、不易因拼写错误导致状态不一致”。这种为什么比只是列了字段更能体现对系统的理解。

讲解视频的录制我建议按照“需求→数据库→后端→前端→部署”的顺序，每段 5 到 10 分钟，不需要一镜到底。任何核心接口用 Postman 现场调一次，展示请求参数、返回结果与预期一致性，这比口头讲一百句都有说服力。新人接手项目时最需要的就是有人带着把请求从头到尾打一遍，所以文档里最好附带一份 Postman 导出文件，这个动作能帮接手的人节省至少一个下午。

7. 常见问题与坑点实录

7.1 数据库层面的典型问题

我遇到的第一个高发问题就是中文乱码。原因基本都是数据库连接时字符集设置不正确。在application.yml里的 JDBC URL 必须带上?useUnicode=true&characterEncoding=utf8，MySQL 建库时也要明确指定utf8mb4。为什么用utf8mb4而不是utf8？因为utf8mb4是完整的 UTF-8 实现，能支持 emoji 和生僻字，这在老人姓名和地址里偶尔会出现，用utf8存储会直接报错或者乱码。

第二个高发问题是时区错误。MySQL 8.0 驱动对时区敏感，JDBC URL 上要加serverTimezone=Asia/Shanghai，否则时间字段会相差 8 小时，或者启动时报 CST 不识别。这个问题在海外服务器上尤其明显，开发环境虽然往往正常，但部署到线上环境就要格外注意区分服务器时区与业务时区。

7.2 后端启动失败与接口异常排查

前端页面能打开但接口全是 404，这类问题我排查过很多次，基本是路径映射没对上。Spring Boot 的默认接口路径是/api/xxx，Nginx 转发时如果proxy_pass末尾带不带/都会影响实际的转发路径，很容易出现多一层或少一层路径的问题。排查方法是先看接口地址和 Controller 的@RequestMapping值是否完全一致，再看 Nginx 转发规则是否有路径重写。

启动时端口被占用也很常见。APPLICATION FAILED TO START报错指向端口占用时，用netstat -tunlp | grep 8080找到占用进程杀掉，或者直接改server.port配置换个端口。如果后端能启动但接口访问特别慢，优先检查数据库连接池是否是默认值，适当把initialSize、maxActive调大一点，对应到 Spring Boot 配置，就是连接池相关参数。

7.3 前端跨域与白屏问题

开发环境下前端跑在 5173，后端跑在 8080，端口不同必然跨域。解决办法是 Vite proxy 配置，把/api前缀的请求代理到后端。生产上如果前端请求的 BaseURL 写成了http://localhost:8080而不是相对路径/api，部署到服务器后大概率也会出问题，因为用户电脑上并没有 8080 端口。正确做法是统一写成/api，让 Nginx 决定转发到哪台服务器。

白屏问题绝大多数原因是打包后的 JS 文件路径错误。Vue Router 用的 history 模式如果没有服务端配置try_files，刷新后 404 或白屏；资源加载路径如果写成了绝对路径/assets/，部署在子目录的时候没有路径前缀就会找不到。此时检查 Nginx 的 root 配置和 Vue 的base属性即可。

7.4 数据库备份与恢复

乡村级系统的数据量不大，但养老数据涉及老人健康信息，丢失会影响很大。线上环境我至少配置两种备份：每天凌晨自动执行一次全库逻辑备份，用mysqldump导出 SQL 文件，保留最近七天；另外每周一次全量物理备份或者直接对云盘做快照。恢复的时候注意要把--set-gtid-purged=OFF这类参数按照运维环境调整，这些在排障文档里需提前注明。

8. 项目后续扩展的方向与心得

这类系统未来的扩展方向很明确，而且不复杂。第一是增加消息推送能力，比如通过微信公众号或短信把老人的健康异常、工单完成情况主动推到家属手机上，这是刚需。第二是增加数据可视化大屏，把全村的老年人数量、服务覆盖率、健康风险分布投到村委的显示大屏上，对基层展示价值很大。第三是可以接入手环、血压计等 IoT 设备，定时同步体征数据，这需要硬件配合，但技术上就是多写一个数据采集接口的问题。

最后说说我自己的感受。开发这类系统，代码写的其实不是难点，难的是把业务规则理清楚。拿工单状态机来说，如果你一上来就写代码，很可能写完发现有一堆边界情况没处理。我现在的习惯是每接一个项目，先拿白板画业务流程图和数据表关系图，图形清楚了再动手，这样开发的返工率能低不少。希望这篇文章能给正在折腾类似项目的你一些帮助，也欢迎在复现过程中有具体问题的话互相交流，把这一类管理系统做得更顺手。