★ FEATURED ARTICLE 最近不少准备做Java毕设的同学找我聊“中华汉字学习平台”这个题目说导师给的题单上写着“JavaSpringBoot Web版国学汉字知识学习系统”听起来很高大上但一动手就懵汉字不是普通字符串拼音排序、多音字、部首检索、学习进度、文化知识关联每一块都能把人绕进去。这篇文章我就以自己实际完成过的同类项目为例把从需求拆解到技术选型、数据库设计、后端接口、Web页面、部署排坑的完整过程写出来全程用SpringBoot这一套东西落地直接可参考。适合正在准备毕设的计算机专业学生也适合想从零做一个完整Web项目练手的朋友。这类平台表面看是“内容展示”实际上比普通商城、博客系统复杂得多。它的核心价值在于“汉字之间有关系”读音联系、部首联系、笔画联系、文化故事联系。把这些关系在数据层面设计清楚后端功能才会好写前端展示才会有内容。下面我就按项目推进的顺序讲明白每一步怎么做、为什么这么做、以及我踩过的坑。1. 项目整体定位与需求拆解1.1 汉字学习平台到底在“学”什么先想清楚一件事这个平台不是“字典的网页版”。字典只负责查字而学习平台要管“学习过程”。用户进来能按拼音找汉字能按部首看字族能每天学一个字能收藏容易忘的字能做记录能看到这个字在成语、诗词、典故里的用法。所以要拆的业务线至少有四条字库管理、检索学习、文化内容、用户学习轨迹。字库管理是底座。汉字本身的信息要足够全字形、读音、声调、部首、笔画、结构、基本释义、详细释义、字源演变、相关词汇、相关诗词。这些字段不是一次就能收集完的做毕设不需要追求覆盖全部汉字准备800到1000个高频常用字和配套文化知识就足够撑起演示效果。常见误区是一开始就想着做两三万个汉字结果数据来源、导入脚本、页面加载全出问题得不偿失。文化内容是这个平台的差异化卖点。如果只做汉字字义评委很容易说“这就是个查询系统”。但当你把“山”字关联到“山高水长”“智者乐山”再关联一篇讲山水文化的文章时整个项目就从“查字典”升级成了“文化学习系统”也真正贴合了题目里“国学汉字知识”这个定位。1.2 核心功能模块与用户角色角色不需要多三类足够游客、注册用户、管理员。游客能浏览字库、看文化文章但一旦要收藏、复习、做测试就必须登录。注册用户可以用学习记录功能比如把某个字标记为“已掌握”把某个字加进错题本。管理员负责维护汉字信息、文化文章、每日一字任务看平台整体的用户学习情况。功能模块我建议拆成六个页面域首页每日一字推荐内容、字库浏览拼音/部首/笔画筛选、汉字详情基础信息文化关联、文化文章列表与详情、个人学习中心进度、收藏、错题、后台管理汉字管理、文章管理、用户管理。这个模块划分对应到Controller上非常清晰分工明确写代码的时候不会东一榔头西一棒子。1.3 为什么选SpringBoot而不是其他方案题目已经锁定了JavaSpringBoot所以这个不用纠结太多。但我想说SpringBoot确实是最适合这种项目的一是中文技术资料极其丰富遇到报错直接搜就能搜到二是自动配置省掉了大量XML配置一个注解就能跑起Web服务三是MyBatis-Plus/JPA等ORM工具很成熟对汉字这种字段特别多的实体比手写JDBC省事太多。有人问要不要用Spring Cloud、Redis、ElasticSearch这些中间件来提升项目档次。我的建议很直接毕设项目优先保证稳定和完整不要为了炫技引入一堆自己都讲不清楚的组件。如果你要加分做一个简单的Redis缓存每日点击量或者用ElasticSearch做全文检索可以但前提是先把基础功能跑通。实际项目中“能用、能演示、能说清原理”比“技术名词多”更重要。2. 技术选型与核心数据设计2.1 版本选择Spring Boot 2.7还是3.x这一步是很多同学噩梦的开始。现在教程五花八门新教程上来就是Spring Boot 3.2.0结果一用MyBatis-Plus就发现不对劲原来写javax.servlet的地方全变成了jakarta.servlet分页插件配置类也换了写法查资料都费劲。我的建议是如果做毕设直接锁定Spring Boot 2.7.x JDK 8或11 MySQL 5.7或8.0 MyBatis-Plus 3.5.1这套组合最稳。如果你非要尝试Spring Boot 3.x也不是不行但要注意MyBatis-Plus必须用3.5.3或更高版本代码里的import javax.*要改成import jakarta.*数据库驱动mysql-connector-j坐标也有变化。这个坑很多同学卡了几个晚上。下面的表格是我个人推荐的最低依赖版本组合组件版本说明Spring Boot2.7.18稳定、资料多、兼容性好JDK8 或 11不要直接上17除非你必须用Spring Boot 3MySQL5.7 或 8.0注意统一utf8mb4字符集MyBatis-Plus3.5.1配合2.7很成熟Hutool5.8工具库处理日期、随机、Bean拷贝非常好用pinyin4j2.5.1汉字转拼音、声调转换Lombok1.18.x减少getter/setter样板代码2.2 汉字信息表怎么设计才能扛住检索需求汉字实体字段多但不要一个表塞所有东西建议拆成多张表否则查询会越来越慢维护也乱。核心表我建议建四张chinese_char汉字主表、char_pinyin_rel多音字读音表、word_article_rel汉字-文化文章关联表、word_idiom_rel汉字-成语关联表。汉字主表字段设计有讲究。以“行”字为例它有两个读音拼音字段如果只存一个按“xing”查它会出现按“hang”查就漏了。所以我用独立的读音表存char_id pinyin tone一条汉字记录对应多条读音记录。查询时先按拼音查读音表取到char_id集合再取主表内容。这个设计比在汉字表里用逗号分隔拼音再LIKE查询要规范得多也是我在项目里反复调整后确定下来的方案。下面是汉字主表的核心字段示例表实际建表时还可以加create_time、update_time等通用字段字段名类型说明idbigint主键char_namevarchar(10)汉字本身unicode_codevarchar(10)Unicode码点如4E2D用于去重和排序radicalvarchar(10)部首total_strokesint总笔画数structurevarchar(20)结构左右、上下、独体等basic_meaningtext基本释义detail_meaningtext详细释义etymologytext字源演变说明audio_urlvarchar(255)读音音频URL可为空2.3 数据来源与批量导入的实用方案数据是汉字学习平台的粮草手工录入几百条要到猴年马月。我实操时用的是两步走先从可靠的开放数据源找一份“常用汉字字典CSV”里面包含汉字、拼音、部首、笔画、释义。CSV一般不太规整我会用Python写脚本做一次清洗再生成SpringBoot能处理的JSON或SQL文件。不推荐在Java代码里硬编码几万汉字维护起来想死。清洗之后再利用SpringBoot的启动加载机制写一个CommandLineRunner启动项目时如果检测到汉字表为空就用EasyExcel或Hutool的CsvUtil读入CSV批量插入数据库。这里有个细节批量插入时一定要用MyBatis-Plus的IService.saveBatch()一次性插入几千条也只需要几秒比循环单条插入快一个数量级。如果数据量大可以考虑分批每500条提交一次避免事务日志过大。还要注意字符集问题。生僻字和一些古代异体字比如“”这类扩展B区文字普通utf8存不了必须整库统一utf8mb4。这个错偶尔等到上线了才暴雷我在第一次导入字库时就在插入“”这种字上直接报Incorrect string value最后把建表语句和JDBC连接URL都改掉才解决。3. 核心功能实现与检索思路3.1 拼音、部首、笔画检索原理与实现先泼一盆冷水千万别直接在SQL里WHERE char_name LIKE %zhang%因为char_name存的是汉字不是拼音。拼音检索的正确姿势是先查读音表再回到汉字表。用户输入“zhang”我们在char_pinyin_rel表里LIKE zhang%或等值匹配得到一串char_id再用WHERE id IN (...)去汉字主表查详情。这样很清晰也不会出现“用汉字字段存拼音”这种尴尬设计。多音字是另一个大坑。“行”字有xíng和háng两个读音如果前端要求用户选择“读音”查询就按读音精确过滤如果不选可以用一个“常见读音”字段来兜底。我实际设计里采用了两层方案char_pinyin_rel存全部读音chinese_char.main_pinyin存最常用的那个读音。列表页按默认常用读音展示详情页把全部读音都显示出来这样既简单又能体现多音字特征。部首检索不建议在汉字表里LIKE部首字段了事因为“氵”“扌”这种部首在Unicode里和汉字共存容易出乱子。更稳的方式是单独建一个radical字典表包含部首ID、部首字符、部首名称、部首笔画数汉字表和部首表之间通过radical_id关联。用户选“水”部实际查的是“氵、水、氺”这些归为水部的汉字这需要一份映射关系。毕设阶段可以简化只把汉字表里的radical字段作为筛选条件排序规则按部首笔画来。笔画查询最简单但也最容易做错。前端要提供的是一个区间比如“5画到8画”不是只让用户填一个数。后端用BETWEEN total_strokes_min AND total_strokes_max查询注意参数要用包装类型不能用int否则前端没传值时默认0会导致条件误判。这些细节有人会忽略但就是在答辩时被追问的“边界情况”。3.2 每日一字与学习计划的数据结构每日一字不应该用“随机函数”糊弄因为随机不仅可能连续两天出同一个字而且让管理员没办法控制内容节奏。我推荐建一张daily_word_plan表字段包括id、plan_date、char_id、word_desc、create_time。管理员在后台提前排好一周或一个月的字用户端按日期查当天内容。如果不想人工维护这么多数据可以做一个“智能生成”功能用定时任务跑Scheduled(cron 0 0 2 * * ?)每天凌晨2点从汉字表里取一个“未分配过”的汉字自动插入今天的daily_word_plan。这个定时任务要做好幂等先查当天是否已有记录有就直接跳过否则会重复插入。为了演示方便可以在后台管理页面加一个“立即生成本周计划”的按钮点一下就循环生成7天数据答辩时操作感很强。那“学习计划”怎么和每日一字区分学习计划是用户维度的用户可以选择“小学通用”“初中进阶”“国学研修”等难度等级系统根据汉字表的difficulty_level字段自动分配一组汉字作为计划。这里不要搞复杂直接用难度等级过滤 每日N个字生成user_study_plan记录就能达到很好的演示效果。我在项目里做了“按难度生成30天计划”的功能只要用户一键选择后台就自动插30条学习记录前端用一个进度条展示完成百分比看起来非常完整。3.3 汉字与文化内容的多对多关联汉字和文化文章之间是典型的“多对多”。一个“水”字可以关联《论语》中“智者乐水”也可以关联成语“上善若水”还可以关联一篇讲中国水文化的长文。反过来一篇国学文章里会包含几十个汉字。所以在关系表设计上我用了两个多对多表word_idiom_rel和word_article_rel。它们字段类似id、word_id、target_id、rel_type、sort_order。这样做的好处是汉字详情页可以直接列关联内容而文化文章详情页也能反查相关汉字互为入口。更高级一点的做法是从文章正文里自动挖掘汉字。比如用HanLP这类工具包做分词把文章里的字或词提取出来再映射到汉字表就能自动建立关联不用人工一条条录。这也是热词里“hanlp分词在springboot”的实际应用。SpringBoot整合HanLP其实很轻松引入com.hankcs:hanlp的jar包然后调HanLP.segment(文本)返回ListTerm。但注意HanLP默认模型文件比较大部署到云服务器时要多占内存毕设演示不一定非要上加分项而已。文化文章正文建议用Markdown格式存储编辑器可以用简单大方的开源组件小项目不推荐上富文本全家桶。后端存markdown_content字段前端用marked.js或者commonmark.js把Markdown转成HTML。这个方案对网络依赖低离线也能渲染而且文章格式非常干净不会出现Word粘贴带来的大段垃圾样式。4. 后端核心业务实现与接口设计4.1 统一结果返回与VO设计后端接口没有统一返回值前端联调会非常痛苦。我从项目一开始就建了ResultT类包含code、msg、data三个字段。code200表示成功其他值表示失败。所有Controller方法都返回这个对象前端Axios统一拦截code不在每个页面重复写错误提示。实体类和前端交互也要做隔离。汉字实体类字段可能超过30个但列表页只需要id、charName、pinyin、radical、totalStrokes这几个字段。如果直接返回实体类不仅会泄露不必要的数据还会因为音频URL、历史释义等大字段拖慢传输。我习惯为每个业务场景建一个VO比如CharacterDetailVO可以合并汉字基础信息、全部读音、关联成语、关联文章一次查询返回完整详情前端少调很多次接口。4.2 一个能直接用的检索接口示例我以汉字列表页最常用的检索接口为例展示关键代码。这个接口支持按汉字名、拼音、部首、笔画区间分页查询RestController RequestMapping(/api/char) public class CharacterController { Autowired private ChineseCharService charService; GetMapping(/page) public ResultIPageCharListVO page(RequestParam(required false) String keyword, RequestParam(required false) String pinyin, RequestParam(required false) String radical, RequestParam(required false) Integer strokesMin, RequestParam(required false) Integer strokesMax, RequestParam(defaultValue 1) Integer pageNum, RequestParam(defaultValue 10) Integer pageSize) { return Result.success(charService.queryCharPage(keyword, pinyin, radical, strokesMin, strokesMax, pageNum, pageSize)); } }对应的Service实现核心是拼接查询条件。这里我用了LambdaQueryWrapper比普通QueryWrapper更类型安全public IPageCharListVO queryCharPage(String keyword, String pinyin, String radical, Integer strokesMin, Integer strokesMax, Integer pageNum, Integer pageSize) { PageChineseChar page new Page(pageNum, pageSize); LambdaQueryWrapperChineseChar wrapper new LambdaQueryWrapper(); // 关键字优先匹配汉字名 if (StrUtil.isNotBlank(keyword)) { wrapper.like(ChineseChar::getCharName, keyword); } // 拼音检索先查读音表拿到charId集合再为主表追加in条件 if (StrUtil.isNotBlank(pinyin)) { ListLong charIds charPinyinRelService.findCharIdsByPinyin(pinyin); if (charIds.isEmpty()) { return new Page(pageNum, pageSize); } wrapper.in(ChineseChar::getId, charIds); } // 部首精确匹配 if (StrUtil.isNotBlank(radical)) { wrapper.eq(ChineseChar::getRadical, radical); } // 笔画区间 if (strokesMin ! null) { wrapper.ge(ChineseChar::getTotalStrokes, strokesMin); } if (strokesMax ! null) { wrapper.le(ChineseChar::getTotalStrokes, strokesMax); } wrapper.orderByAsc(ChineseChar::getTotalStrokes); return charService.page(page, wrapper).convert(this::convertToVO); }这里有两个容易踩的细节。第一keyword只能匹配汉字本身别想着同时模糊匹配拼音那是两套逻辑混在一起非常难调。第二pinyin查询时如果用户输入的是“xing”表里存的是“xíng”声调可能有差异所以我建议在读音表里同时存“带声调拼音”和“不带声调拼音”查询统一用不带声调的那个字段去匹配。这样“xing”“xíng”都能命中体验会好很多。4.3 学习记录、收藏与错题本的核心表个人学习相关的功能表结构要围绕“用户-汉字”这个组合展开。核心是user_word_progress表字段包括id、user_id、char_id、study_status、familiarity、mistake_count、last_review_time、next_review_time。其中study_status可以枚举未学习、学习中、已掌握。familiarity用0到100的整数表示熟练度每次学习就加5答错就扣10简单直观。收藏和错题本可以共用一张表加一个biz_type字段区分FAVORITE表示收藏MISTAKE表示错题。这样不用建三张结构类似又没什么区别的表而且查询时一个接口就能处理两个页签。另一个关键点是用户行为表要加联合唯一索引UNIQUE KEY uk_user_char (user_id, char_id)防止用户重复点击学习导致同一字产生多条记录。出现重复数据后页面进度百分比可能超过100%这种小bug在答辩时特别掉价。复习提醒做不做做。不要上消息队列、短信提醒就在学习中心页展示“待复习列表”按next_review_time NOW()查询即可。还可以做一个简单的“间隔重复”策略第一次学完后24小时复习之后7天、30天各复习一次。这个策略写在代码里也不复杂但对项目完整度加分非常多给人一种“你不是在写玩具系统”的感觉。4.4 登录注册与权限控制怎么选型毕设项目别动辄上Spring Security OAuth2那一套配置量大看不懂容易翻车。我建议用“拦截器 JWT”的方式用户登录成功后后端生成一个token返回前端前端每次请求放在Authorization头里后端拦截器解析token再放行。这个方案代码量小而且你能把JWT的结构、签名、过期时间讲得明明白白答辩反而更从容。注册逻辑不要只存用户名密码密码要做哈希处理。用BCryptPasswordEncoder或者Hutool的BCrypt.hashpw()千万别存明文密码。这是安全底线也是一眼就能看出来的专业细节。注册时可以顺带填一个“学习阶段”字段比如小学、初中、成人这个字段后面给“学习计划生成”提供依据属于一举两得的字段。后台管理接口要和控制用户学习的接口分开最简单的做法是给管理员账号单独一个role字段拦截器里校验角色。不要搞微服务级别的权限中心更不要用自定义注解AOP做花哨的权限模型项目体量不到那个程度。把/admin/**下的请求都拦截并校验admin角色就够了。5. Web端页面与展示细节5.1 Thymeleaf还是Vue怎么选才最合适这个问题的答案取决于你更擅长什么。如果对前端不太熟建议直接用Thymeleaf服务端渲染Controller返回视图名配合一个简单的HTML模板数据刷出来就能用代码里也不用处理跨域、token存哪这些问题。缺点是页面交互不够“现代”每次操作都要刷新。如果前端有一点基础我强烈推荐用Vue 3 Vite Axios做前后端分离页面。写起来更接近真实企业项目而且页面效果明显更好。这里就有热词里说的“vue打包放进springboot中”经典操作npm run build之后把dist目录下的所有静态文件复制到SpringBoot的src/main/resources/static目录SpringBoot启动后就会自动托管这些静态资源。访问http://localhost:8080就是你写好的前端页面后端接口前缀用/api完美共存。要注意一个大坑Vue Router如果用了history模式部署到SpringBoot后直接刷新某个子页面会报404因为后端没有对应的路由。解决办法有两个一是改用createWebHashHistory()URL里会带个#刷新没问题二是在SpringBoot里加一个WebMvcConfigurer把非/api的路径都转发到index.html。我在项目里两种都试过毕设演示图省事用hash模式最稳。5.2 汉字卡片页的展示与拼音声调处理汉字详情页是整个平台的颜值担当。一个大的汉字居中展示旁边标注拼音带声调、部首、笔画、结构下面再放释义和关联内容。视觉上推荐用大号的书法字体比如“站酷快乐体”或“演示春风楷”比系统默认字体更有国学味道。字体文件可以放到本地static/fonts下避免运行时加载外部资源失败。拼音声调是技术细节里的重头戏。Java后端通过pinyin4j把汉字转成带声调的拼音核心配置代码如下import net.sourceforge.pinyin4j.PinyinHelper; import net.sourceforge.pinyin4j.format.HanyuPinyinOutputFormat; import net.sourceforge.pinyin4j.format.HanyuPinyinToneType; import net.sourceforge.pinyin4j.format.exception.BadHanyuPinyinOutputFormatCombination; public String toPinyinWithTone(String hanzi) throws BadHanyuPinyinOutputFormatCombination { HanyuPinyinOutputFormat format new HanyuPinyinOutputFormat(); format.setToneType(HanyuPinyinToneType.WITH_TONE_MARK); return PinyinHelper.toHanYuPinyinString(hanzi, format, , true); }得到的xíng这种带声调符号的字符串前端直接展示即可。多音字要格外小心PinyinHelper.toHanYuPinyinString默认会返回多个读音拼接通常取第一个常见读音作为展示详情页再用“读音列表”展示所有读音。我碰到过一个很烦的问题同一个“乐”字在“快乐”里读lè在“音乐”里读yuè如果平台没有上下文语境只能把所有读音都列出符合“多音字学习”的需求。笔画动画可以做但优先级靠后。用SVG的path配合CSS动画或者第三方库都能实现不过数据成本很高每个汉字的笔画顺序都要准备一份JSON数据工作量巨大。我建议第一版只做“笔画数展示”和“描红效果”也就是用Canvas画一个大的汉字轮廓用户能在上面写字后端不保存笔迹仅做交互。这样演示效果有了开发量又可控。5.3 首页与个人学习中心的产品逻辑首页不用堆信息四块足够顶部导航、每日一字卡片、汉字分类入口、推荐文化文章。每日一字卡片是首页C位调/api/char/daily返回当天的汉字带上拼音、释义、一个关联成语。这个卡片做得好不好直接决定平台给人的第一印象。我做过一版是纯文字卡片后来改成“汉字水印背景 上方大字 下方拼音”整体气质立刻不一样了答辩评委也明显更有兴趣。个人学习中心则要清楚展示三样东西整体学习进度、今日待办、错题列表。整体进度可以用一个进度条已学字数/计划总字数数据来自user_study_plan和user_word_progress的统计。今日待办来自每日一字和复习计划。错题列表不用长列出最近20条就够了每条显示汉字、错误次数、最近错误时间点击就能跳转详情页重新学习。这里如果时间充裕可以用ECharts画一个“熟练度分布饼图”学习中心立刻有数据可视化的感觉比表格高级不少。6. 常见问题与实操排坑记录6.1 MySQL中文、生僻字、emoji入库报错怎么办这个错误几乎人人会遇到报错信息一般是Incorrect string value: \xF0\x9F\x98\x80 for column xxx。原因很简单表字符集是utf8不是utf8mb4而中文生僻字和emoji需要4字节存储。解决办法分三步把数据库、表、字段都改成utf8mb4JDBC连接串加上characterEncodingutf8mb4如果建表语句已经写了DEFAULT CHARSETutf8一定要改过来再重新执行。还有一个小坑MySQL 5.7下即使表字符集是utf8mb4如果排序规则用了utf8_general_ci对汉字的排序也只是按Unicode码点排不是按拼音排。所以任何“按拼音首字母排序”的需求都不能依赖数据库排序要在后端把拼音字段算好再sort。我在项目里直接给汉字表加了一个pinyin_sort字段专门存“不带走声调的拼音字符串”比如“爱”存“ai”排序就按这个字段来稳得很。6.2 SpringBoot版本太高引发的兼容性问题清单用新版本不是不行但如果网上教程大多停留在2.x你就会发现很多代码贴进去都报错。我总结过一份排查清单遇到这几个问题按表检查。问题现象可能原因解决方案ClassNotFoundException: javax.servlet.FilterSpring Boot 3.x换了Jakarta命名空间改用2.7.x或把代码里的javax.*改成jakarta.*MyBatis-Plus内置分页失效分页插件配置类没扫描到检查MybatisPlusInterceptor配置并把PaginationInnerInterceptor加入MySQL driver连接报时区错误JDBC URL缺时区参数连接串加serverTimezoneAsia/ShanghaiAutowired报错但代码没问题可能是构造器注入顺序或Bean扫描路径不对检查启动类是否在主包MapperScan是否写了正确包名静态资源404Vue打包文件放错目录放到src/main/resources/static并确认没有把dist文件夹嵌套两层这个表我在辅导学生时已经用了很多次基本能解决80%的初始化问题。这里面最坑的还是“版本太高”本身很多同学并不需要3.x的新特性纯粹是新项目模板默认生成高版本一上来就给自己挖坑。6.3 定时任务在测试和部署中的注意事项每日一字定时任务不是写完就完事。第一测试环境如果开着EnableScheduling每天凌晨真的会执行第二天打开数据库发现多了条记录这没问题但如果你反复改代码重启可能一天插入好几条因为任务每次项目启动都重新运行。解决办法是配置里加一个task.enabled开关测试环境设false只有正式部署才开。第二定时任务失败要有日志。用Scheduled默认没有自动补偿如果当天任务执行失败用户端每日一字就是空的。我的经验是在executeDailyTask()方法里先查一次计划表如果没有今天的记录才生成如果生成失败至少要打log.error方便排查。为了保险可以给页面接口做一个兜底/api/char/daily查不到当天计划时自动从汉字表选一条常用字返回保证前端永远不会白屏。这也是答辩时能讲出的容错设计。6.4 答辩演示的加分细节最后聊点“软实力”。这个项目功能不复杂但在答辩时想拿高分要主动把你的设计亮点讲出来。我一般建议准备以下三个演示顺序先讲每天的“每日一字”是怎么从计划表里取出来的突出你设计的数据结构和定时任务再演示按拼音查“行”字故意展示多音字处理说明你不是只会LIKE查询最后演示一个“生成学习计划”或“错题本”的操作把用户维度的逻辑串起来。数据库设计方面准备一张简单的ER图不需要复杂重点是能解释清楚char_pinyin_rel为什么独立成表、user_word_progress为什么加唯一索引。架构图也不需要微服务就画一个“浏览器 - SpringBoot - MySQL”的三层图再标出JWT拦截器位于哪个位置就足够应付提问了。答辩老师最反感的是“代码跑起来但说不清”你只要能把每个设计选择背后的理由讲明白就已经超过大多数人了。我个人带完这个项目后最大的体会是汉字学习平台看着不大但它把“内容管理”“检索设计”“用户轨迹”“文化关联”四个方向全串在了一起非常适合用来体现完整的Web开发能力。如果你也被这个题目卡住别急着怼代码先把汉字表设计好、把多音字想清楚、把每日一字的数据流理顺后面就是一条线的事。最后再分享一个小技巧做每日计划时不要用随机数把常用字按难度分个级按顺序轮播数据既有规律又可解释演示时说服力强得多。
阅读完成 · 觉得有帮助？
