企业官网建设流程全解析

做了大半年Java全栈，手上最值得复盘的一个项目就是这套基于SpringBoot和Vue的获奖作家信息管理系统。名字有点长，但功能非常聚焦：把获奖作家的整套档案资料——生平、代表作品、获奖记录、媒体报道、照片这些，从散落在各个Excel、Word里的原始状态，收拢到一个前后端分离的Web系统里，统一管理、快速检索、清晰展示。这套系统不是什么高并发大流量项目，但它把"档案类管理系统"最常见、最实际的需求全走了一遍。

这个项目的适用场景很明确：出版社的编辑资料库、文学馆的作家档案室、高校文学院的教学案例库，甚至作协的内部资料管理都能直接套用。对正在学JavaWeb或者准备毕业设计的同学来说，它的价值在于技术栈非常正统——SpringBoot做后端，MyBatis操作MySQL，Vue搭前端，ElementUI做页面组件，从数据库设计、接口开发、页面渲染到打包部署，一条完整链路全打通。我下面把整个项目的设计思路、核心实现和踩过的坑完整拆一遍，重点讲"为什么这么做"，以及哪些地方是真的要用教训换来的。

1. 项目背景与核心需求解析

1.1 需求是这么挖出来的

要理解一个系统，先得搞清楚它服务的对象和日常场景。我接这个项目时，客户方是某文化研究机构，他们手里积累了数百位当代获奖作家的资料，但形态非常原始——一个大文件夹里按作家名字建子文件夹，里面有生平Word、作品PDF、获奖记录表Excel、新闻报道截图，文件名命名规则还不统一，有人叫"某某简历"，有人叫"作家某某2023资料"，查一个人的完整信息要翻半天。

更头疼的是统计口径。负责人问"今年有多少位作家获得过国内重要文学奖项？"答不上来；问"获得两个以上重要奖项的作家有哪些？"只能人工拿Excel筛，费时费力还容易出错。这就是典型的"数据都有了但信息出不来"。所以这套系统的首个硬需求非常明确：把非结构化的散落资料，变成结构化的数据库记录，让检索和统计可以靠SQL直接解决，不用再靠人肉翻文件夹。

我梳理需求时把它拆成了四个核心模块：作家档案管理，管姓名、笔名、出生年份、籍贯、简介这些基础信息；作品管理，一个作家对应多部作品，记录作品名称、类型、出版年份；获奖管理，记录获奖时间、奖项名称、颁奖机构，支持按奖项类别筛选；资料附件管理，处理作家头像、作品封面、媒体报道截图这类图片上传和展示。这四个模块不是我拍脑袋定的，而是从他们日常最高频的操作习惯里提炼出来的。做管理系统最忌讳一上来就堆功能，先问清楚"谁在用、每天干什么、最烦什么"，比急着写代码重要得多。

1.2 系统到底解决了什么

搞清需求之后，系统的定位就很清晰了：一个典型的档案类MIS系统，技术上没有多高深的算法，核心就是"把CRUD做扎实、把体验做顺手"。我给产品定了几个明确的操作层目标：列表检索要快，支持按姓名、作品名、获奖年份做组合筛选，秒出结果；录入要顺手，出生年份用下拉选择、获奖日期用日期控件管住，不能让人随手乱填；统计要直观，列表里直接展示作家的获奖次数，还能按奖项类别排序；权限要够用，管理员能增删改，普通用户只能查看检索，防止误操作。

这四条目标直接决定了后面的表结构、接口划分和前端页面布局。很多同学做管理系统上来就设计五六个角色、搞复杂的RBAC权限模型，实际上对这种几十人使用的内部系统来说，一个管理员加一个普通用户就已经足够了——过度设计只会拖慢开发进度。这是我做这个项目最深的体会之一：需求边界划得越清楚，代码量直接砍掉一半，交付质量反而更高。

2. 技术选型与架构设计思路

2.1 后端为什么是SpringBoot加MyBatis

技术选型是这类项目绕不开的话题。先说我为什么没选更重的企业级方案。SpringBoot现在基本是Java后端的事实标准，它最大的价值在于"约定优于配置"——以前用SSM框架要手写一大堆XML配置，SpringBoot把内嵌Tomcat、自动配置、Starter依赖管理全给你省了，我一个人能把工程快速搭起来。对于这种规模的管理系统，SpringBoot的启动速度和开发效率优势非常明显，团队成员也都不用再为环境配置扯皮。

数据访问层我选了MyBatis而不是Spring Data JPA，原因很实在：管理系统的列表页经常需要多条件组合查询，SQL的灵活度非常重要。MyBatis允许手写SQL，动态拼接条件用<if>和<where>标签非常直白，排查问题也方便——直接把SQL拿出来放到数据库工具里跑一遍就能定位问题。JPA写简单CRUD确实快，但复杂查询的条件拼接反而不直观，而且新手很容易踩N+1查询的坑，排查起来比MyBatis麻烦得多。

数据库选定MySQL 5.7版本，理由不用多说，生态成熟、部署方便、资料多。这里有一个我必须强调的细节：建库时字符集一定要指定utf8mb4，千万不要图省事用默认的latin1或者utf8。等你录入作家简介时遇到生僻字、特殊符号，就知道这个设置的厉害了。我用的排序规则是utf8mb4_general_ci，对中文排序完全够用，真正录入作品名里的书名号和中文标点也都能正常存储显示。

2.2 前端为什么是Vue加ElementUI

前端一开始我也犹豫过，要不要用传统的JSP加Bootstrap做服务端渲染。但权衡之后还是决定用Vue做前后端分离，理由有三点。第一，列表页的筛选、排序、分页这类交互，用Vue的数据绑定做起来比JSP用jQuery操作DOM舒服太多，代码写起来省一半。第二，前后端分离之后，后端只提供JSON接口，前端独立成工程，两边可以并行开发，晚上改前端页面根本不用重启后端服务。第三，Vue生态里的ElementUI组件库正好覆盖了管理系统的所有通用组件——表格、表单、弹窗、上传、日期选择器——基本都是开箱即用，省去造轮子的时间。

前端选型这块有个实际的执行细节：我用的Vue版本是2.x而不是3.x，配套的是ElementUI 2.x。为什么不追新？因为当时项目成员更熟Vue2，ElementUI 2.x的文档和社区问答数量最多，遇到问题搜一下就有答案，开发效率最高。做项目不是炫技，稳定和可维护优先。如果你现在从零开始做，用Vue3加Element Plus也完全没问题，整体思路是一样的，只是个别写法有差异。

2.3 一次请求是怎么跑通全链路的

为了让新手对整个系统有整体感，我描述一下"查看作家列表"这个请求的完整路径。浏览器打开前端页面，Vue调用axios发起GET请求到后端接口，比如/api/writer/list?page=1&size=10&keyword=某作家。请求到达SpringBoot的Controller层，Controller校验参数后转给Service层；Service层处理完业务调Mapper接口，MyBatis根据Mapper XML里写的SQL去MySQL执行查询；结果逐层返回，最终以JSON格式回到axios的then回调里，Vue把数据渲染到表格组件。整个链路每层各干各的事，这就是分层架构的意义——出问题的时候你能快速定位到底在哪一层。

还有一件被我视为"基础设施"的事：统一返回体设计。我定义了一个Result类，包含code、message、data三个字段，成功时code为200，失败时为500，业务异常时code为某个特定值。前端axios拦截器里统一判断code，正确就返回data，错误就弹出提示。这个习惯非常重要——如果每个接口返回格式都不一样，前端就要到处写判断，后期维护能把人逼疯。这也是为什么你在很多项目里都会看到类似Result、R、ResponseResult这类类名的原因，大家都是在早期吃过不统一的亏才养成的习惯。

3. 数据库设计与核心表结构

3.1 核心表的设计思路

这个系统的表结构一共五张：用户表、作家表、作品表、获奖记录表、附件表。我重点讲作家表和获奖记录表，因为这两张关系到核心业务。作家表的主要字段包括：主键id、姓名name、笔名pen_name、性别gender、出生年份birth_year、籍贯native_place、简介introduction、头像avatar、状态status、创建时间create_time、更新时间update_time。

这里有一个容易被忽略的设计点：出生年份我用了int类型，而不是date类型。为什么？因为业务上只需要"年份"这个粒度来做筛选和排序，不需要精确到月日。如果存完整日期，反而平白增加转换成本，前端展示还得做格式化。类似的判断在整个表设计里出现过很多次：字段类型不是越精确越好，而是越贴合业务越好。你存一个永远用不到的时分秒，只会给自己添麻烦。

获奖记录表是另一个核心，字段包括：主键id、作家id、奖项名称、奖项类别、获奖年份、颁奖机构、获奖说明。奖项类别这个字段属于典型的"业务枚举字段"。我一开始想用Java枚举来限制可选值，写死几个选项，但后来发现文学奖项种类实在太多，而且还会不断新增分类——用枚举反而难维护，最后改成字符串字段，管理端用下拉框选择，选项从字典表里读取，以后要加分类不用改动代码，加一条字典记录就行。对小型管理系统来说，这个取舍非常划算。

3.2 表关系与外键取舍

五张表的关系并不复杂：作家表与作品表是一对多，一部作品只属于一个作家；作家表与获奖记录表是一对多，一个作家可以有多次获奖经历；作家表与附件表也是一对多，但我把附件设计成了"多态关联"——附件表里有一个biz_type字段区分是作家头像还是作品封面，还有一个biz_id字段指向对应业务记录的ID，这样一张附件表就能服务所有业务的图片需求。

多态关联在互联网项目里很常见，但很多教学项目里用得少。不少同学会直接给作家表和作品表各加一个图片字段存路径，以后要加"媒体报道截图""证件扫描件"这类新附件类型时，又得改表结构加字段。我统一用附件表管理的好处就是扩展方便：以后新增任何附件类型，不需要改表，只要约定好biz_type的取值就行。

外键这块我特意说明一下：物理表上我没有真的加FOREIGN KEY约束，只用了逻辑外键，就是普通索引字段，靠业务层代码保证关联完整性。原因有两个，一是MySQL在外键约束下删除数据顺序有讲究，运维不灵活；二是这个系统的写入频率不高，外键的"保护"意义有限。但这个取舍要分场景——如果你是要交课程设计作业，建议还是把外键加上，因为很多评审老师会专门检查这个点，逻辑外键说不清楚容易被扣分。

3.3 索引设计：优先考虑高频查询

几百条数据的表，查询性能完全不是瓶颈，但索引还是要建对的，这是职业习惯问题。我给几张表的高频查询字段加了索引：作家表的name字段加普通索引，因为列表页最高频的操作就是按姓名搜索；获奖记录表的writer_id加索引，因为"查看某作家的获奖列表"是最频繁的子查询；作品表的writer_id也加索引，原因相同。

有人会问，为什么不给奖项名称加索引？因为按奖项名称筛选的频率远低于按作家查，而且奖项名称字段区分度不高，索引收益有限，反而浪费存储空间。做索引的正确姿势不是把所有列都加上，而是先列清楚查询频率，再对高频查询建索引。这个思路跟写代码一样，先想清楚业务，再谈优化。

4. 后端核心功能与实现细节

4.1 工程结构与分层约定

后端工程按经典的三层架构组织，包结构一目了然：controller层只接收参数、调用service、返回Result，不做任何业务逻辑；service层处理所有业务判断和事务控制；mapper层负责数据库操作；entity层放实体类；config层放配置类；common层放公共工具和统一返回类。

Controller层我要求自己只做三件事。一开始我也图省事直接写过逻辑进Controller，结果后来需求变化——比如删除作家前要检查是否有作品和获奖记录——Controller里到处都是业务代码，根本没法维护。重构之后清爽多了，这也让我更坚定一个原则：Controller越薄越好。很多新手以为分层是形式主义，其实它是后期可维护性的命根子。

4.2 Mapper层：注解与XML的配合

Mapper层我用的是混合做法：简单的单表增删改查用注解，多条件的动态查询用XML。原因是动态SQL在注解方式里写起来容易串引号、可读性很差，而XML里的<where>标签配合<if>判断，缩进和逻辑一目了然。下面这段是作家列表分页查询的Mapper XML核心片段：

<select id="selectByCondition" resultType="com.example.writer.entity.Writer"> SELECT * FROM writer <where> <if test="keyword != null and keyword != ''"> AND name LIKE CONCAT('%', #{keyword}, '%') </if> <if test="awardLevel != null and awardLevel != ''"> AND id IN (SELECT writer_id FROM award WHERE award_level = #{awardLevel}) </if> </where> ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} </select>

标签会自动处理掉多余的AND，避免手写拼接时多出一个AND导致的SQL语法错误，这个细节刚用MyBatis的人常常栽跟头。分页这里我用的还是手写LIMIT，没有引入PageHelper插件。说实话对这种几百条数据的表，两种方式性能没差别，手写LIMIT更透明，面试被问到也好解释。更重要的一点是，用LIMIT分页前必须ORDER BY排序字段唯一，否则分页数据会重复——我一般会在排序最后加上id作为次级排序键，比如ORDER BY create_time DESC, id DESC。

4.3 登录鉴权：JWT加拦截器

这个系统有管理员和普通用户两种角色，登录是必须做的。我用的方案是JWT加拦截器，没有引入完整的Spring Security框架。登录流程：用户提交用户名密码，后端校验通过后，用用户的ID和角色生成一个token返回给前端；前端把token存到localStorage，每次请求在请求头带上Authorization字段；后端写了一个拦截器，统一拦截需要登录的接口，从token里解析用户信息，校验失败直接返回401。

密码存储方面我用的是BCrypt加密，没用MD5。原因是MD5已经被彩虹表破解得七七八八，自己加盐的实现又容易写错；BCrypt自带随机盐，每次哈希结果都不一样，计算成本还可以调高，是业界推荐的密码哈希方案。有的同学为了省事直接把密码明文存库，我强烈不推荐，哪怕只是内部系统，密码泄露一次就是事故。项目里我单独引入了BCryptPasswordEncoder这个类来生成和校验密码，不依赖Spring Security的其他组件。

权限控制这块没有引入完整框架，原因很简单：这个系统的权限模型实在太简单了，只有"管理员/普通用户"两种角色，用拦截器判断token里带过来的角色字段就够了。引入完整Spring Security意味着要写大量过滤器配置、重写登录逻辑，学习成本高，对当前项目的价值却有限。但如果你是拿这个项目做毕业设计，我建议把Spring Security补齐配置逻辑，答辩时能成为一个亮点，安全架构的完整性也更好看。

4.4 逻辑删除：档案类系统的底线设计

删除功能是我认为这个系统里最需要谨慎处理的点。我设计的是逻辑删除而非物理删除——作家表里有一个status字段，删除时把status改成0，列表查询默认只查status为1的记录。这样设计最大的好处是误删了还能恢复。档案类业务有一个特点就是"可恢复性"非常重要，你永远不知道客户会不会在删除三个月后突然说"那个作家的资料我还要用"。如果你亲手经历过去数据库里帮客户恢复误删数据的痛苦，就会明白我为什么在这个点上这么坚持。

另外我还做了一个保护性校验：删除作家前，后端会检查该作家名下的作品表和获奖记录表是否有数据，如果有，就返回一个提示"该作家名下还有N部作品和M条获奖记录，确认删除？"给前端弹二次确认。这个设计也来自一个真实教训——第一次部署给测试人员用的时候，删除一个作家后，他的获奖记录直接变成孤儿数据，列表页查询时因为关联了不存在的作家ID直接报错。加上这个关联检查，类似问题从根上解决了。

4.5 文件上传与静态资源映射

作家头像和作品封面需要上传功能，我用的方案是本地存储，没有引入对象存储服务。后端接收MultipartFile，把文件写到服务器的upload目录，文件名用UUID加原始后缀重命名，避免中文名和重名引发的乱码、覆盖问题。然后把"相对路径"存到附件表，接口返回给前端后，由前端拼接完整URL访问。

这里有一个必须注意的配置：SpringBoot默认的静态资源路径是classpath下的static目录，需要把本地上传目录映射为可访问的静态资源路径，否则前端拿到/upload/xxx.jpg会直接404。我在application.yml里做的配置如下：

spring: servlet: multipart: max-file-size: 5MB max-request-size: 20MB web: resources: static-locations: classpath:/static/,file:${upload.path}

文件大小限制一定要配。我很清楚地记得第一次调试时，传一张作家肖像一直报错，排查了半天才发现是SpringBoot默认的1MB限制在作怪。部署时的路径也要注意：上传目录最好用绝对路径，别用相对路径，否则在不同启动目录下会找不到文件，生产环境尤其要谨慎。

5. 前端页面设计与交互实现

5.1 前端工程与路由守卫

Vue工程我用脚手架搭建，核心目录包括路由配置、axios接口封装、页面视图组件、公共组件和axios实例封装。路由配置里我用到了前端路由守卫，原理是每次路由跳转前检查localStorage里有没有token，没有就强制跳转到登录页。这算页面级的访问控制，能提升用户体验——用户没登录进入系统时直接被弹回登录入口。

但必须强调一点：前端路由守卫和按钮级别的隐藏，永远只是体验优化，不是安全机制。真正的安全校验只能靠后端接口层。任何前端代码都能被绕过，一个懂技术的人完全可以绕过页面直接调接口。所以这个系统的后端拦截器才是真正的安全底线，前端隐藏按钮只是让普通用户少看到入口而已。很多新手把前端"藏按钮"当权限控制，这是一个很大的误解。

5.2 作家列表页与表单页

作家列表页是整个系统使用频率最高的页面。设计时把筛选区放在顶部，包括姓名关键词输入框、奖项类别下拉框、状态下拉框、查询按钮和重置按钮，下面是带分页的表格。表格列包含姓名、笔名、出生年份、获奖次数、状态、创建时间和操作按钮。这里要特别说下"获奖次数"这个列的数据来源。

获奖次数不是数据库里的冗余字段，而是在后端查询时用一个聚合子查询实时计算出来的：

SELECT w.*, (SELECT COUNT(*) FROM award a WHERE a.writer_id = w.id) AS award_count FROM writer w

这样列表页拿到的一行数据就已经包含了统计信息，前端不用再为展示"获奖次数"做二次请求。这种查询时计算汇总字段的方式，在小数据量下性能完全没有问题，还省去了维护冗余字段时的一致性麻烦——如果数据库里存了一个获奖次数字段，每次新增获奖记录都要记得同步更新，漏一次数据就错了。

表单页用了ElementUI的表单组件配合校验规则：姓名必填、出生年份必须是四位数字、简介长度限制500字。校验规则我的原则是"前端做一层，后端也做一层"。前端校验是为了用户操作体验，填错了立即提示不用等请求回来；后端校验是为了数据安全，因为绕过前端直接调接口的请求是拦不住的。两层不能互相替代。

5.3 前后端联调的常见弯路

前后端联调是这个项目最耗时间的环节，而且大部分时间不是花在写代码上，是花在"对字段名"上。我踩过一个很典型的坑：后端实体类字段是createTime，驼峰命名，前端JavaScript对象里拿到的JSON字段也是createTime，但ElementUI表格列的prop属性我写成了create_time、带下划线的，结果这一列死活不显示数据。

这种问题定位起来其实很简单，打开浏览器控制台看接口返回，对比一下字段名就明白了，但我那次找了好久。解决办法就是养成好习惯：前端表格列的prop必须与接口返回的字段名严格一致。要么全部用驼峰，要么全部用下划线，千万别混着来。这也是为什么很多团队会约定：后端实体统一驼峰，前端表格统一照抄，从源头消灭这类低级问题。

跨域问题也是前后端分离标配要处理的。开发环境下前端跑8080端口、后端跑8081端口，必然存在跨域。我开发时在后端写了一个WebMvcConfigurer配置类，允许指定来源的跨域请求，这只是开发便利。上线后我用Nginx做反向代理，把前端和后端统一到同一个域名下，从根上规避了跨域。生产环境不建议完全放开跨域限制，只放开你域名白名单里的来源就够了。

6. 高频问题排查与避坑实录

6.1 高频问题排查速查表

开发、测试、部署三个阶段我遇到了不少问题，整理成了一张速查表，按症状、根因、解法来排，方便以后遇事直接对着查：

6.2 三个最想提醒的坑

第一个是日期类型传输问题。Java后端用LocalDateTime，JSON序列化默认格式是一长串UTC时间戳，前端ElementUI的日期组件根本不认这种格式，展示出来极其难看。解决办法是统一配置Jackson的日期格式，在application.yml里加上日期格式和时区配置，这个问题就能根除。我当时没配这个，导致创建时间列显示成奇怪的数字串，查了半天资料才反应过来是时区加序列化格式的问题。别再踩了。

第二个是MyBatis的驼峰映射问题。数据库字段是create_time，Java属性是createTime，如果map-underscore-to-camel-case这个配置没有开启，查询结果里createTime这个属性永远是null，因为MyBatis不知道把下划线字段映射到下划线属性。这个配置默认是false，一定要手动打开。我见过不止一个人因为这个字段全是null，就在实体类里加了一堆 @JsonProperty 注解来救场，那是治标不治本，正确做法就是开配置。

第三个是分页参数的防御校验。测试人员输入page等于-1时，SQL里的LIMIT -1, 10会直接报错。我在后端加了一行简单判断：page小于1时强制改为1，size大于100时改为100。这种参数防御看起来琐碎，但系统交付后谁都会乱点，前端校验根本拦不住，后端必须有这条底线。类似的还有字符串参数的空值判断、长度限制，这些都是后端开发的基本功。

6.3 一套有效的排查方法论

遇到问题不要瞎猜，我给自己定了一个调试顺序。第一步，开浏览器F12看Network面板，确认请求有没有发出去、请求参数对不对、响应状态码是什么、响应体内容是什么。如果响应体报了500，就去后端控制台看异常堆栈。第二步，如果后端没有异常但数据不对，把MyBatis打印SQL的日志配置打开，看实际执行的SQL长什么样，再把SQL复制到数据库客户端里手动跑一遍，基本就能定位是SQL问题还是数据问题。

这个流程听起来简单，但真的能解决90%的问题。很多同学一遇到报错就急着去搜索引擎复制粘贴异常摘要，结果搜到的都是八竿子打不着的答案，不如老老实实按自己的调用链从接口往下追。调试能力是写代码之外最重要的基本功，做全栈项目尤其如此，因为你既要懂前端请求，又要懂后端逻辑，还要会看数据库执行计划，三样缺一不可。

7. 环境搭建、打包部署与后续扩展

7.1 运行环境与打包部署

这套系统的运行环境要求很朴素：JDK 1.8以上、MySQL 5.7以上、Maven 3.6以上，前端构建需要Node.js 14以上。后端打包用Maven的package命令生成jar包，因为SpringBoot内置Tomcat，直接java -jar xxx.jar就能跑起来。前端用npm run build生成dist静态目录，生产环境我建议用Nginx托管dist目录，再配一个反向代理把/api开头的请求转发到后端端口。

这里放一个Nginx的关键配置参考：

server { listen 80; server_name your-domain.com; location / { root /opt/writer/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

try_files那一行是最关键的配置，它保证前端路由在刷新页面时不返回404。如果不加这个配置，用户从列表页刷新到详情页会直接白屏，因为Vue是单页应用，刷新时浏览器会向服务器请求那个"不存在的路径"。

7.2 存量数据迁移与初始化

系统上线前要导入客户手里已有的存量数据。由于老资料都在Excel里，我写了一个临时数据导入工具：用EasyExcel读取Excel文件，映射到后端实体类，再批量插入数据库。这里有一个很实用的经验：批量插入时不要一条条执行INSERT，MyBatis的批量插入语法效率会高一个数量级。几百条数据一条条插可能感觉不出来，但几万条数据对比就非常明显了。

还有一个细节是初始化管理员账号。项目启动时我监听ApplicationRunner事件，检查用户表是否为空，为空就自动插入默认管理员账号，密码用BCrypt加密。这样部署时不需要手动往数据库插数据，交付体验好不少。当时我踩过一个小坑：密码初始化用的明文，第一次登录后怎么都校验不过，后来才发现初始化逻辑里忘了加密步骤，改完之后问题立刻消失。

7.3 后续可以怎么继续扩展

这个系统的扩展空间还挺大，我梳理过几个真实业务中会遇到的迭代方向。第一个是档案导出功能，把列表页查询结果一键导出成Excel，这是管理系统的刚需，领导要报表的时候不用再截图整理。第二个是作家详情时间线，把获奖记录按年份排成一条纵向时间线，直观展示一个作家整个创作生涯的荣誉轨迹，这个功能展示效果非常好，属于投入小、口碑好的功能。第三个是全文检索，当简介和作品介绍文本量变大时，引入MySQL全文索引可以提升搜索体验，比LIKE模糊查询更高效。

我个人在后续迭代里最想做的其实是"作家详情档案视图"——从一个作家的详情页直接看到他的完整作品列表、获奖时间线和所有附件资料，形成一页式的档案总览。技术上不复杂，但使用体验提升非常明显，也符合档案管理"一看即全"的核心诉求。

这套系统做下来，我最深的感触是：管理系统从来没有技术上的深水区，真正的深水区在业务理解上。你把客户的操作习惯琢磨透了，把数据之间的关系理清了，代码反而会顺理成章地被推着写出来。另一个体会是，做全栈项目一定要把每个环节都亲手跑一遍，从数据库建模到前端联调再到打包部署，完整走一遍之后，你对"一个系统是怎么跑起来的"会有完全不一样的理解。如果你正卡在类似项目的某个环节，希望这篇拆解能帮你少走一段弯路。