我在招聘网站上翻前端岗位的端毕要求，发现一个扎心的业设事实：超过七成的初级岗位写着“要求两年以上经验”。可应届生哪来的端毕两年经验？于是毕业设计就成了唯一的筹码——它要证明的不是你会写代码，而是业设你能把代码变成能用的东西。

我见过太多人把毕设做成“教程合集”。端毕首页是业设轮播图，下面跟个表单验证，端毕再放个天气API，业设完事。端毕这种项目看着功能不少，业设可面试官一问“为什么用flex不用grid”，端毕答不上来。业设更致命的端毕是，整个项目没有一条完整的业设数据流——用户点完按钮，数据去哪了？端毕刷新页面后还在吗？没人关心。

真正能打的毕设，通常长这样：它解决一个具体到有点琐碎的问题。我有个同学做的是宿舍报修系统，界面糙得跟Windows 98似的，但他把“报修单状态流转”做透了——提交、接单、维修中、待验收、已关闭，每个节点都有时间戳和操作记录，还做了个简单的消息推送。答辩时老师追着问“并发维修单怎么处理”，他直接打开数据库演示了锁表策略。最后拿了优秀毕设，面试时聊了四十分钟这个项目，当场拿到offer。

不是说技术栈不重要。Vue、React总得会一个，但关键是你怎么用。我见过有人用Vue全家桶做了个博客系统，所有文章存在localStorage里，刷新不丢，但也仅此而已。问他“为什么不用后端”，他说“后端是Java的，不熟”。这暴露了真实职场里的核心问题——前后端协作不是靠“熟”解决的，是靠接口约定。哪怕你只写前端，也得知道后端返回什么结构、错误码怎么处理、加载中是什么状态。

我自己的毕设走了条野路子。学校图书馆的座位预约系统难用得要命，每天早晨抢座跟打仗似的。我花了三周扒了它的接口，用React+Antd重做了个前端，加了“常用座位收藏”和“抢座失败自动捡漏”功能。没做后端，数据全mock，但交互逻辑完全是真刀真枪的——倒计时、请求节流、错误重试、座位状态实时刷新。答辩时老师问“你这数据是真的吗”，我说“接口是真实的，但只做了只读”。他们反而来了兴趣，问了一堆跨域、token失效、接口幂等的问题。

那三周我每天写代码到凌晨两点，不是为了分数，是因为真的想用。这种真实需求驱动的项目，代码量可能不如管理系统大，但每个分支都是实际踩坑踩出来的。比如座位状态更新的竞态问题——两个用户同时选同一个座位，你得处理后一个的失败提示，而不是直接覆盖。这种细节，教程里永远不会教。

写毕设最忌讳的就是“为了做而做”。你选个“在线商城”模板，改改图片文字交上去，能过，但面试官一眼就能看出来。他会问“秒杀功能你怎么设计”，你只能说“没做”。反过来，你要是做了个“宿舍二手交易平台”，哪怕只实现了发布、搜索、私信三个功能，但把图片压缩、防重复提交、聊天消息的未读计数都处理了，这就是实打实的能力证明。

最后说点实在的。代码写完，记得写README，把启动步骤、技术选型理由、遇到的坑都写清楚。答辩时照着念都行。再录个两分钟的操作演示视频，比PPT管用一百倍。别把毕设当成任务，它其实是你第一次有机会自己定义问题、自己设计方案、自己承担后果的完整项目。这个过程中养成的习惯——比如每次改完代码先跑一遍全流程回归，比如注释里写“为什么”而不是“是什么”——会跟着你进第一份工作。

前端这行，工具每年都在变，但解决问题的思路不变。毕设是你唯一能完全掌控的战场，别浪费它。

(责任编辑：焦点)