写这个项目之前我先聊点题外话。国内很多信息管理系统尤其是高校、文化机构里跑着的那一套套“XX管理系统”看起来五花八门但内里翻来覆去就是那几套技术框架在扛。这次这个“企业级当代中国获奖知名作家信息管理系统”名字长做的事情其实非常聚焦把作家档案、获奖记录、代表作品、媒体报道这些零散的数据收拢到一个SpringBootVueMyBatisMySQL的完整栈项目里。说白了就是一套典型的、可复用的管理后台加了一层文学行业特有的人物画像逻辑。这篇文章我打算从需求拆解、技术选型、数据库建模、后端核心接口、前端落地一路讲到排查实录把一条龙过程里我自己觉得最有价值的部分掰开揉碎了说清楚。适合正在做毕设、接私活或者公司里要快速搭一个同类信息管理系统的朋友参考。1. 需求看懂了大半项目就成了大半很多开发者在做这种所谓“管理系统”的时候第一反应是冲进MyBatis写CRUD写到一半才发现字段对不上、权限漏风、报表没法看。我个人的习惯是先花两三个小时把需求问透再决定怎么动工。1.1 别小看“获奖知名作家”这几个字这个项目表面上是个作家信息管理实际上关键字全在“获奖”和“知名”这两个限定词上。这意味着系统里管理的不是泛泛的作家名单而是一个带有“荣誉履历”和“影响力标签”的专项档案库。从产品逻辑上讲它天然就有两个核心矛盾要解决作家基础信息和获奖经历之间不是简单的从属关系。一位作家可以有多项获奖记录同一奖项也可能由不同作家在不同年份获得。如果把获奖信息直接冗余在作家主表里后续查询“某奖项的所有获奖者”或者“某年度所有获奖记录”会非常痛苦。“知名”是一个模糊的、可量化的运营概念。系统里需要设计一套标签或权重体系用来标记作家的影响力层级比如“重点跟踪”“一般关注”“新锐潜力”等。这种东西没有固定的数据库标准答案纯粹是业务口在提需求时大家一拍脑袋定的但你做系统时就必须把它落成一张字典表。想清楚了这两点后端的表结构就有了大概的轮廓。这个项目采用独立获奖记录表、独立标签字典表再加关联关系的设计我觉得在这类文化内容管理系统里是合理的。1.2 用户角色和权限边界越早定越好改几乎每一套系统都会被人问“谁能看谁能改谁能删”。作家信息管理这种内容型系统常见的角色无非是三类系统管理员、资料维护员、普通访客。但最后一类经常被忽略。很多项目的权限设计只在后端写死一个LoginInterceptor但这套系统做了细化的做法管理员可以维护用户、分配角色、删除数据维护员负责作家档案和获奖记录的增删改访客或者普通注册用户只能查询、浏览、导出公开数据。这里我强调一点不是越精细越好而是要和实际使用场景匹配。我就见过某机构的内部系统权限粒度细化到“能不能看某位作家的出生日期”结果运维成本高到没人愿意配置最后只能把权限全开给管理员形同虚设。所以这次实际编码时前端路由做了动态权限过滤后端接口通过SpringBoot的拦截器加注解实现角色校验。不求粒度细到字段级但至少做到页面级和操作级的控制。你拿着普通账号登录很多按钮压根不渲染就算你手动调接口后端也会返回401或403。2. 这套技术组合为什么十多年了还这么能打SpringBootVueMyBatisMySQL说句实话这套组合在国内的项目里出现频率高到已经有点“烂大街”了。但你不得不承认它依然能打。它的魅力不在于“新”而在于“稳”和“好招人”。我接过的私活里十有八九甲方指定就要这个技术栈。2.1 SpringBoot把繁琐的配置收进自动装配里SpringBoot最大的贡献不是它多快多强而是把Spring生态里曾经繁琐得要命的XML配置基本消灭了。以前搞个SpringMVC要配web.xml、配dispatcher-servlet.xml、配数据源、配事务管理器光是让一个HelloWorld跑起来就能劝退一批新手。现在一个spring-boot-starter-web依赖拉进来内嵌的Tomcat主启动类一跑完事。用它做企业级项目核心还是要理解它给你封装了什么。比如自动配置、约定优于配置、起步依赖这三大件决定了你排错时的思考方向。项目里出问题十有八九不是你的业务代码错了而是某个自动配置类的条件装配没生效。理解了这一点排查问题会顺手很多。2.2 MyBatis控制狂的福音SQL还是自己写的香MyBatis被很多人吐槽“写SQL麻烦”但在我这类老派开发者眼里它反而是优势。JPA和Hibernate那种全自动ORM处理简单实体关系时确实省事但一旦遇到多表联查、复杂统计、报表聚合要么得写JPQL要么得调底层方言反而更难受。MyBatis把SQL的执行权完全交到你的手里。以这个系统为例查询某位获奖作家的完整荣誉列表需要关联作家表、获奖记录表、奖项字典表三张表还要按年份排序、按奖项级别过滤。这种场景写一段手撸的关联SQL清晰又高效。而且MyBatis的动态SQL标签像if、where、foreach搭配起来做条件查询那真是灵活得让人放心。中间有一点要注意MyBatis默认的驼峰映射经常让人踩坑。数据库字段award_nameJava属性awardName如果不开启map-underscore-to-camel-case查出来这个字段就是null。这个配置在新版本里默认是开启的但如果你用的是旧版本或自定义配置就必须在application.yml里面显式地加一条。2.3 Vue前后端分离的甜谁分离谁知道前端用Vue特别是配Element UI这类组件库做中后台开发效率是很高的。这套系统里Vue最核心的价值在于组件化和响应式。比如作家信息编辑页面基础信息、获奖经历、代表作品、媒体评价四处内容完全可以拆成四个子组件各自维护自己的数据状态父组件只做汇总提交。用户在前端页面上做的每一次增删改操作都不需要刷新页面数据的双向绑定会自动触发视图更新。这种开发体验比传统的JSP加jQuery时代不知道舒服了多少倍。当然Vue这块也有一个要提醒的点组件通信别乱用。能props传的就props传能emit出去的就emit出去最多用个Vuex管理登录态和全局字典。最怕的是为了省事把Bus事件总线满项目飞最后出了bug都不知道是哪里触发的事件。2.4 MySQL作为主力数据库够用且舒服MySQL在这套架构里就是最底层的数据底座。作家信息、获奖记录、用户权限、操作日志全部落在MySQL上SQL语句查询、事务处理都依赖它。选择它而不选那些NoSQL数据库原因在于这类系统的数据结构化程度极高事务一致性要求也高。比如一位维护员同时给一位作家添加三项获奖记录如果第三次插入失败前两次必须回滚。这种强一致需求NoSQL数据库做起来要么不支持、要么很别扭但MySQL加Spring的Transactional注解几行代码就解决得明明白白。3. 数据库设计决定项目上限的永远是地基数据库设计是这类管理系统里最见功力的一环。很多新手上来就建表字段随用随加表之间外键全靠冗余最后跑起来能查数据但扩展性和维护性一塌糊涂。这个项目的数据库设计我觉得可以拿出来说说因为它既没有过度设计又基本覆盖了业务所有的查询场景。3.1 六张核心表管住作家的一辈子我设计这套表结构时遵循的原则是核心实体一张表附加属性拆字典动态数据拆流水。拆解下来核心表包括作家基本信息表、获奖记录表、奖项字典表、作品表、用户表、用户角色表。先说作家基本信息表。字段不外乎姓名、笔名、性别、出生日期、籍贯、民族、文学体裁标签、代表作品数、简介、封面图URL、状态等。这里有个容易被忽略的点姓名和笔名一定要分开存。实际业务中很多获奖作家发表作品时用的是笔名档案材料里个人情况用的又是真实姓名检索时两边都要能命中。如果只存一个字段将来想按“笔名”做模糊搜索就得把字段拆开或加冗余列非常折腾。再说获奖记录表这是体现“获奖”核心价值的关键。每条获奖记录要关联作家ID、奖项字典ID、获奖年份、颁奖机构、作品名称、获奖等级等。奖项字典表单独拆出来的好处是奖项名称统一维护不会出现“鲁迅文学奖”和“鲁奖”这种同义不同名的脏数据。作品表不用做太重不做全文只做基础索引。作家主页需要展示代表作清单所以作品表存作品名称、作品类型、首次发表年份、所获特殊荣誉等即可。如果业务以后要做作品详情页再往深里扩展。用户表和角色表走最常见的RBAC模型。用户表存账号密码BCrypt加密存储、昵称、状态角色表存角色编码和名称。中间加一张用户角色关联表一个用户可以有多个角色但实际项目里通常一个用户只会有一个角色。关于数据库层面为什么不用外键这里多说一句。很多人建表时喜欢加FOREIGN KEY觉得数据完整性有保障。但实际开发中尤其是MyBatis环境下我们设计索引约束也好、字段约束也好都偏向于把这张表当成一个独立的数据集合来对待。所有的完整性校验都放在Service层代码里做数据库只负责存数据。这样做的原因是外键会降低数据导入导出的灵活度在分库分表或数据迁移时会成为绊脚石。当然如果你连Service层校验都做不好那我建议你还是老老实实加外键至少兜个底。3.2 索引怎么加是从查询场景倒推的索引不是越多越好每多一个索引插入和更新就要多维护一棵B树。所以要加索引必须倒着从查询场景反推。这个系统最主要的查询场景无非几个按作家姓名或笔名模糊搜索对应作家表的姓名、笔名联合索引按文学体裁标签筛选作家列表对应体裁标签字段的普通索引按奖项名称查询所有获奖作家对应获奖记录表的奖项字典ID索引加作家ID索引按获奖年份维度统计获奖情况对应获奖记录表的获奖年份索引。其中最核心的查询一定落在获奖记录表上。所以我在获奖记录表上建了一个(award_id, writer_id, award_year)的联合索引既覆盖了“查某个奖项的获奖者”场景又能支撑“查某位作家的获奖列表”场景。联合索引最左前缀原则在这种查询场景下是发挥了大作用的。3.3 状态字段和逻辑删除千万别把数据删没了做管理系统的朋友应该都懂用户或者管理员手滑删除一条数据是经常发生的。如果直接把这条记录DELETE掉数据恢复将变得非常被动。所以在设计所有核心表时我都加了is_deleted这个逻辑删除字段。0表示未删除1表示已删除。前端调删除接口时后端执行的其实是UPDATE语句把is_deleted置为1。所有查询SQL默认都带WHERE is_deleted 0条件。这操作看着不起眼但在实际项目里救过我太多次了。还有一个容易被忽略的排序字段。作家列表往往需要管理员手动排序比如把重点跟踪的作家往前排。所以作家表里加了一个sort_order字段默认值是0列表SQL统一先按sort_order DESC再按create_time DESC排序。这样管理员调整展示顺序时只需更新一条数据的排序值即可不用改SQL。4. 后端核心模块实现从Controller到Mapper的完整链路这个项目后端部分我按业务模块切成几条线来写作家管理、获奖记录管理、用户认证与权限控制、数据看板。每一块都不复杂但串起来就是一个完整的企业级项目骨架。4.1 分页查询和条件搜索一个PageHelper就够作家列表页是系统最核心的页面。这个页面的查询条件通常有关键字匹配姓名、笔名、简介、文学体裁、获奖状态、状态等。SpringBoot后端接收这些条件封装成一个查询对象传给ServiceService调Mapper接口查询数据库。项目里的分页用的是PageHelper这个插件。很多老开发者对这个插件感情复杂觉得它好用是好用但就是因为太好用导致很多人根本不知道底层原理。其实PageHelper的原理并不复杂拦截即将执行的SQL根据PageHelper提供的分页参数自动改写SQL拼接上LIMIT关键字。使用它的唯一要求就是分页插件必须在查询语句之前设置页码和每页条数。一旦顺序搞反分页就会失效而且不会报错会一次性查出所有数据。当后端返回数据时我封装了一个统一的返回对象Result。里面包含状态码code、提示信息msg、数据体data。分页查询的数据体里又包含total总记录数、rows当前页数据列表、currentPage当前页码、pageSize每页条数。这样前端翻页组件拿数据的时候逻辑非常清晰。4.2 获奖履历的增删改事务是底线新增或编辑一位作家时通常要同时维护他的获奖记录列表。前端传来的请求体里是一个作家基础信息对象加上一个获奖记录对象数组。后端Service层要做的就是在一个事务里先保存作家主表信息再循环保存每一条获奖记录。这里我踩过一个大坑一开始为了偷懒在循环里逐条调用单条插入的Mapper方法结果接口性能极慢。保存10条获奖记录要执行10次数据库交互。后来改成用MyBatis的foreach标签做批量插入性能一下提升了将近十倍。三万条测试数据量下批量插入和三万次单条插入的耗时差距不是一个量级的。事务这块我明确要求自己用Transactional注解而且重点理解它的回滚规则。很多人只知道这个注解能开事务却不知道它默认只在遇到RuntimeException和Error时才回滚。如果你的Service方法里抛了受检异常比如FileNotFoundException事务是不会自动回滚的数据就可能出现半截提交的情况。所以后来我写事务方法时要么写Transactional(rollbackFor Exception.class)要么统一在方法内捕获受检异常并对外抛出RuntimeException。4.3 用户登录和JWT令牌无状态认证的正确打开方式前后端分离的项目登录认证一般不采用Session那一套而是用JWT。流程是前端提交账号密码后端校验成功后生成一个令牌返回给前端。前端每次请求时在请求头里带上这个令牌后端拦截器解析令牌、取出用户身份、校验权限。JWT核心是Header、Payload、Signature三部分。Header一般声明算法和令牌类型Payload里放用户基本信息Signature是用Base64编码后的Header和Payload加一个密钥用指定算法签名生成。签名的意义在于防止令牌内容被篡改。如果有人改了Payload里的用户名Signature验证就能被发现异常。后端拦截到请求后先从请求头取令牌再解析验证。通过后把从令牌中解析出的用户信息放入ThreadLocal之后Controller层直接通过工具类获取当前登录用户。这里有个细节要留意ThreadLocal用完后一定要调用remove方法清除不然在高并发复用线程池的场景下线程变量残留会导致拿到上一个人的用户信息。这个BUG极其隐蔽复现起来时灵时不灵非常恶心人。4.4 数据看板用几个SQL撑起管理员的导航页系统里给管理员做了一个数据概览页展示几个核心指标作家总数、获奖记录总数、奖项种类数、按年份统计的获奖趋势。这些数据完全可以通过聚合SQL搞定。比如按年份统计获奖趋势的SQL就是SELECT award_year, COUNT(*) FROM award_record GROUP BY award_year ORDER BY award_year。按文学体裁统计作家分布就是SELECT genre, COUNT(*) FROM writer GROUP BY genre。这些SQL用MySQL跑一下几毫秒就出结果。很多时候业务方要求的所谓“大屏看板”数据计算根本不复杂复杂的是图表美化。而后端要做的无非就是提供几个聚合接口。5. 前端落地Vue组件化和页面交互的那些细节后端写得再漂亮前端如果交互稀烂用户照样骂娘。这个项目的前端基于Vue2加Element UI组件库开发既有基础信息表单也有列表页、详情抽屉、弹窗确认等场景。前端这一块我主要讲几个真正影响使用体验的取舍。5.1 列表页的搜索与重置作家管理列表页顶部是搜索栏包含关键字输入框、文学体裁下拉选择框、获奖状态下拉框、搜索和重置两个按钮。这里的交互细节在于搜索时页码要重置为1不能停留在第5页搜搜完用户一脸懵重置时要把所有条件清空重新加载第一页数据。下拉框的数据来源统一调后端接口获取字典项。字典项会在登录成功后拉取一次存在Vuex里列表页、下拉搜索框、编辑弹窗里都从Vuex中取避免每个组件都重复请求接口。表格列的设计上姓名和笔名两列合并展示显示为“姓名笔名”的格式方便运营人员快速识别。操作列提供“编辑”“详情”“删除”三个按钮。删除按钮点击后弹出二次确认框文案明确提示“删除后数据将移入回收站可在回收站中恢复”起到防止误操作的作用。5.2 编辑页的组件化拆分编辑页是操作最复杂的页面。我把它拆成了四个Tab或四个卡片区域基础信息、获奖经历、代表作品、媒体评价。每个区域独立成一个Vue子组件父组件负责收集所有子组件的数据统一提交。以获奖经历子组件为例它内部维护一个获奖记录列表。用户操作“新增获奖记录”就会在列表里多一行编辑表单填写奖项名称、获奖年份、颁奖机构、代表作品。用户操作“删除”就把那一行从本地数组里移除。这个子组件内部还有一个奖项名称的自动补全控件用户在输入时组件会调接口匹配奖项字典表提示可选奖项。这功能做出来运营的录入效率高了不少。提交时父组件会把基础信息对象合并获奖记录数组作为请求体发给后端。后端接收后在Service层统一处理。这里要注意的是子组件内部表单校验必须各自完成如果有一行获奖记录没填年份前端就要拦截提交不要等到后端返回SQL异常了才提示。5.3 路由守卫和按钮级权限控制前端路由配置里通过动态路由表按用户角色生成可访问的路由。后端登录接口返回的令牌中带有用户角色编码前端拿到角色编码后动态向路由实例添加对应权限的页面路由。普通注册用户那就只能看到作家列表和详情页系统管理、用户管理、日志管理这些页面压根不会注册到路由表里。按钮级权限的控制方式我封装了一个自定义指令比如v-permissionadmin。模板里出现这个指令的按钮在组件挂载时判断当前用户角色是否匹配不匹配就直接把DOM节点移除。使用这种方式的好处是按钮权限逻辑复用成本极低哪需要权限控制往按钮上加一行指令属性就能解决。5.4 前后端联调时的跨域和异常处理前后端分离项目的联调阶段最烦的就是跨域。本地开发环境前端跑在8080端口后端跑在8081端口前端发起请求时浏览器的同源策略会拦截跨域响应。解决方案一般两种后端加CORS配置或者前端利用Vue的开发服务器配代理。我习惯用后者的方式因为后者的配置只在开发环境生效部署到生产环境后前后端通过Nginx反向代理天然同源。Vue开发服配置代理的方式是在vue.config.js里配置devServer.proxy。配好之后前端请求的路径带/api前缀代理会把请求转发到后端的接口地址。联调时另一个关键点是前端全局异常处理。我封装了一个统一的请求工具类所有请求都走这个工具。后端返回的Result对象中code不等于200时前端统一弹Message提示后端返回的msg网络异常、超时这些情况单独拦截处理。这样联调时一旦出问题前端会弹出具体的后端报错信息不用再拿浏览器DevTools慢慢翻Network面板排查。6. 常见问题与排查实录项目上线前一定要过一遍这些坑项目自己跑通演练和真上生产被一群人点着用完全是两种感受。下面这几个问题都是这套系统实际运行中坑过我的我把它整理成一张速查表方便你以后直接参照。问题现象根本原因解决方案后端接口查询列表超时数据库表数据量较大后未加索引的字段被用于排序或过滤给高频查询字段补联合索引优化SQL避免全表扫描前端页面白屏控制台报跨域错误开发环境未配置Vue代理或后端CORS未放开在vue.config.js配置devServer.proxy或后端配置CorsFilter日期字段从前端传到后端始终为null前端传递的时间字符串格式与后端解析格式不一致后端日期解析注解中配置pattern yyyy-MM-dd保证两端格式一致PageHelper分页失效查出一整页全部数据分页参数设置在查询SQL之后或PageHelper被多次调用干扰调整代码顺序确保分页参数紧贴查询设置中间不穿插其他逻辑JWT接口偶发获取到上一个用户的信息线程池复用时ThreadLocal变量未清理对ThreadLocal使用后调用remove方法或者改用请求结束时的Filter统一清理批量插入作家获奖记录时速度极慢循环中逐条插入数据库交互次数过多改为MyBatisforeach批量插入或使用ExecutorType.BATCH执行器表单提交后部分内容消失前端组件数据未正确绑定或Vue响应式数据更新未触发视图刷新使用Vue.set或直接替换数组对象确保响应式数据变更可检测后端接口报主键冲突或唯一索引异常导入作家时未做幂等控制重复提交在Service层增加基于作家名称和出生日期的唯一性校验6.1 分页失效类的疑难杂症PageHelper分页失效的问题值得单独拎出来再讲一遍。出现场景往往是在一次查询里先调了一个不需要分页的查询方法再调了分页查询方法结果导致SQL解析错乱。PageHelper采用的是ThreadLocal实现分页参数的传递这意味着一旦你在一个线程里先执行了分页查询再执行另一个查询如果两者共用同一个ThreadLocal而没有清空那么第二个查询会被误加上LIMIT。解决办法是严格执行分页标准写法先PageHelper.startPage(pageNum, pageSize)紧接着就是需要分页的那一条查询SQL中间不要穿插任何其他Mapper方法调用。如果确实要在同一个Service方法里执行多次查询那就在分页查询执行后立刻用PageHelper.clearPage()清空参数。6.2 日期格式的统一问题作家信息里充斥着出生日期、获奖年份这类时间数据。前端日期选择器默认返回的是yyyy-MM-dd格式而后端Java对象里如果字段类型是LocalDateSpring本身能够自动转换。但是如果你在实体里用的是Date类型且前端通过JSON传的是1990-08-15 00:00:00这种带时间的字符串后端反序列化时就需要在全局配置中设置时区以及日期格式。项目里最稳妥的方案是在配置文件里统一指定日期格式化格式并且在所有实体类上使用JsonFormat(pattern yyyy-MM-dd)注解确保序列化和反序列化格式一致。同时数据库连接字符串上加上serverTimezoneAsia/Shanghai参数解决MySQL驱动8.0版本对时区的严格校验问题。这几个配置不做好日期字段的bug会伴随着整个项目的维护周期反复出现。6.3 权限校验绕过风险权限这块后端校验时最容易犯的错是只校验“是否登录”不校验“是否具备操作权限”。比如编辑接口只判断了token ! null没有判断当前用户角色是否允许编辑。实际系统上线后就可能出现普通注册用户通过直接调用接口的方式修改了作家数据的情况。我的排查经验和建议是后端拦截器里除了解析令牌还要从令牌中取出角色编码在进入Controller执行前完成角色权限校验。同时涉及敏感操作的接口必须在Service层再加一遍权限校验。两层校验看着冗余但这是防止越权操作的最直接方式。7. 部署上线从打jar包到Nginx反向代理项目开发完成最重要的就是部署上线这一步。前后端分离项目的部署通常是将后端打包成可执行的Jar包部署到服务器上由Java环境运行前端打包成静态资源文件部署到Nginx的静态目录同时通过Nginx反向代理把/api开头的请求转发到后端的服务端口。7.1 后端打包的几个注意点SpringBoot项目打包使用Maven的package命令即可生成Jar包。但有两个配置建议提前处理。第一排除项目里的DataSource自动配置检测避免打出来的包在运行时因加载不必要的配置而报错第二配置文件里不要写死数据库连接地址应使用环境变量占位符。比如url: jdbc:mysql://${DB_HOST}:${DB_PORT}/writer_db这样在不同环境下部署时只需在服务器的环境变量中配置即可不需要重新打包。启动命令方面推荐使用后台启动方式并且记录启动日志。一个标准的启动命令是nohup java -jar writer-system.jar --spring.profiles.activeprod log.log 21 。用nohup脱离终端会话用挂到后台日志输出到指定文件方便排错。这套命令当年帮我在云服务器上少开了无数个终端窗口。7.2 前端静态资源部署Vue项目打包后生成dist目录。把该目录下的文件全部拷贝到服务器指定目录例如/usr/share/nginx/html/writer。Nginx配置文件里的location /设置为该目录并配置try_files $uri $uri/ /index.html这是SPA路由模式下必须配置的否则刷新前端页面就会出现404。同时配置/api开头的路径反向代理到后端地址。配置完毕后执行nginx -t校验配置语法再执行nginx -s reload让配置生效。这一套下来系统就算真正面向用户了。7.3 数据库初始化脚本和定时备份新建数据库时一次执行初始化SQL脚本把所有表结构和基础字典数据一次性建好。项目自带了初始化脚本包括建库、建表、插入管理员账号等操作。生产上线后定时备份务必安排上。我常用的方式是用系统的cron任务每天凌晨执行MySQL的mysqldump命令将全库数据压缩打包保存到另一块磁盘或对象存储里。备份脚本加上日期后缀保留最近30天的备份文件避免磁盘不够用。8. 写在最后做管理系统这些年最大的心得是什么从这套系统立项、设计、开发到上线回头看去技术本身其实没有太多惊天动地的突破SpringBoot、Vue、MyBatis、MySQL每一个都是开发者耳熟能详的老朋友。但把一个看似普通的需求做到完整、顺手、不返工这里面确实有一些书本上没写明白的东西值得沉淀下来。我个人的体会是管理系统技术框架选型的权重远没有需求边界和数据结构设计高。代码哪里写得不好后续都能重构但如果连“作家、获奖、作品、奖项字典”这些基础实体的关系都没理清那后续所有页面新增和接口扩展都会举步维艰。所以当你接到一个类似的信息管理系统不管前面的人怎么催你先花半天把数据库设计磨扎实把角色权限想清楚把分页查询格式定好这比多写十个接口都值。最后分享一个小技巧。这个系统后来接了一个新需求给每位作家生成一句话简介用于门户网站轮播图展示。这种新增字段的小需求按传统流程要改表、改实体、改前端表单、改动辄好几个文件。但因为前期数据库设计时预留了简介字段后端实体统一封装了字段映射前端编辑页基础信息组件里顺手加了文本域整个需求从提出到上线前后不到一个下午。这就是前期设计冗余带来的长效收益。做管理系统真的别嫌前期思考麻烦后面返工才叫真的麻烦。
