做了这么多年开发，也陆续指导过不少朋友完成毕设项目，发现一个很有意思的现象：凡是选“预约类系统”当题目的，几乎没有毕不了业的。原因很简单，这类系统业务边界清晰、角色分明、技术栈组合固定，而且理发店、健身房、汽车保养这种线下服务场景人人都能理解，写需求分析和答辩解释时都省力。今天我就拿“SSM + Vue 理发预约系统”这个组合，从选题拆解、数据库设计、前后端实现到论文怎么写，完整过一遍思路和实操，把平时不会写在文档里的经验一并交代清楚。
1. 项目整体的设计与思路拆解
1.1 理发预约系统的业务本质是什么
先别急着写代码，任何一个预约系统的核心，其实都是在解决一个极其朴素的问题：让顾客和店员之间关于“谁来服务、什么时候服务、做什么项目”这件事，从线下扯皮变成线上确定。
理发场景有几个区别于其他预约系统的特点。第一，理发师和项目之间存在绑定关系，总监级别的师傅和普通发型师能服务的项目不完全一样，所以不能简单做一个“项目表”完事。第二，理发的耗时差异很大，剪发半小时，烫染可能两三个小时，所以预约时段需要支持跨小时甚至跨时段。第三，用户有“指定发型师”的需求，也有“随机安排”的需求，这两种预约逻辑不一样。
基于这个理解，系统的角色可以拆成三类：普通用户（顾客）、理发师、管理员。用户端做的是注册登录、浏览项目和发型师、提交预约、查看和取消预约、对已完成的服务做评价。理发师端做的是查看自己的日程安排、确认或拒单、维护自己的可预约时段。管理员端负责整个后台，包括用户管理、理发师信息管理、服务项目管理、预约单管理，以及最基础的统计报表。
1.2 为什么选SSM而不是Spring Boot
到2026年了，很多学生会直接问：老师，现在新项目都用Spring Boot，为什么毕设还要用SSM？这个问题必须正面回答，因为答辩的时候老师大概率会问。
SSM指Spring、SpringMVC、MyBatis三个框架。它和Spring Boot之间的关系，可以类比成“自己组装电脑”和“买品牌整机”。Spring Boot把大量配置帮你做好，开发体验更现代，但SSM模式下每一个Bean的装配、每一次Mapper的动态代理、每一次DispatcherServlet的拦截流程，都需要你亲手配置和感知。对于教学场景和毕业设计来说，SSM恰恰能体现你对框架底层原理的理解程度。
从实际答辩角度说，SSM项目有一个Spring Boot项目不具备的优势：你可以在论文里光明正大用一整章篇幅去写“框架集成与配置”，解释applicationContext.xml里怎么扫描Service、springmvc.xml里怎么配置视图解析器、MyBatis的SqlSessionFactory怎么把mapper接口和XML映射文件绑起来。这一章写好了，论文字数瞬间就不愁了，而且每一个配置都是有技术含量的，不是硬凑字数。
另外还有一层现实考虑：网上海量的毕设源码里SSM占了很大比例，遇到问题时搜索“spring mvc mybatis 报错 XXX”基本能直接命中别人踩过的坑，对新手友好得多。所以用SSM做毕设，是一个兼顾技术深度、论文写作和实现难度三者平衡的选择，单从“毕设”这个目标来说，非常合适。
1.3 Vue在前端扮演的角色和整体架构
前端选择Vue，目的很直接：把页面从传统的JSP模板渲染解放出来，改用前后端分离模式。理发预约系统里信息展示的实时性要求并不高，但交互复杂度不低。用户的预约状态会变化，后台的统计图表需要动态更新，管理员的审核操作需要即时反馈，用Vue的响应式数据绑定处理这些场景，写起来比原生jQuery舒服太多。
技术选型建议固定为Vue 2 + Element UI。2026年Vue 3早就是主流了，但如果你用Vue 2，网上能找到的SSM + Vue项目案例、博客和踩坑记录是最多的。如果你对Vue 3更熟，用Vue 3 + Element Plus也可以，但后端接口不变，顶多注意一下Axios的导入方式和生命周期钩子名称差异。
整体架构可以画成一条链路：浏览器里的Vue单页应用，通过Axios发起HTTP请求，请求到达SpringMVC的DispatcherServlet，Controller接收参数并调用Service层，Service层通过MyBatis的Mapper接口操作MySQL数据库，处理完成后的JSON数据再原路返回给前端渲染。整个过程无页面刷新，数据和视图单向流动。
2. 数据库设计与核心表结构
2.1 核心表拆解与字段规划
数据库是整个系统最需要花心思的地方，表设计得好不好，直接决定后面写代码时是行云流水还是到处打补丁。理发预约系统我认为六张表足够覆盖全部业务，不用贪多。
用户表保存账号密码手机号昵称和头像，密码记得存MD5或加盐加密后的密文，直接用明文是会场事故级别的错误。理发师表需要单独建，因为理发师有工号、职级、擅长项目描述、头像和个人介绍，这些字段放在用户表里会让表结构变得乱七八糟，而且理发师和后台管理员、顾客是完全不同的业务角色。
服务项目表存项目名称、价格、预计耗时（用分钟为单位，不要存字符串），以及这个项目可以被哪些职级的理发师服务。这里设计上可以预留一个level_required字段，比如最低需要中级理发师。预约表是核心中的核心，字段要包含顾客ID、理发师ID、项目ID、预约开始时间、预约状态、备注和创建时间。评价表绑定订单ID，记录评分和内容。
最后一类是轮播图表，如果有精力可以做，不做也不影响功能完成度。很多学生喜欢把表设计得特别多，觉得表多代表系统复杂，其实是给自己挖坑，不仅数据流绕，论文写起来也乱。六张表、三张业务主表、三张支撑表，这个规模对本科毕设来说刚好在“饱满但不冗余”的甜点区。
2.2 预约表的状态设计与时间字段陷阱
预约表的状态字段建议用int类型，0代表待确认、1代表已确认、2代表已完成、3代表已取消。为什么要用数字不用字符串？一是存储开销小，二是代码里比较方便，三是后期如果要扩展状态（比如加一个“爽约”），加一个数字就行，不用动数据库结构。
时间字段是最容易出问题的地方。举例说明：预约开始时间appointment_time建议用datetime类型。前端Vue里用日期选择器选好后，传过来的是一个字符串，比如“2026-05-20T14:30:00.000Z”。如果你在Controller里直接用String接收，再存进数据库，大概率会出现时区偏移问题，明明选的下午两点半，库里存的是晚上十点半。
正确的做法有两种。后端接收时在实体类字段上加上@DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss")注解，同时前端在提交前先用dayjs或moment把时间格式化成YYYY-MM-DD HH:mm:ss再传输。我自己的习惯是前后端各处理一次，前端保证格式干净，后端做好兜底解析，双保险。这条经验我写在每个预约类项目里，因为踩的人实在太多了。
2.3 外键到底要不要建
很多教科书会告诉你，表与表之间要建外键约束，保证数据一致性。这话没错，但在实际项目中，尤其是我带过的多个毕设项目里，外键在日常开发中反而常常带来麻烦。
举个例子：用户要删除账号，如果订单表里有外键指向用户表，你就必须先确保这个用户没有任何订单才能删除。但业务规则可能是“用户注销后订单记录保留一年，用于对账”，这时候外键就成了障碍，你只能先改业务代码再改数据库结构。而在SSM + MySQL这套组合里，MyBatis本来就不强制依赖外键，代码层面通过业务逻辑保证了引用完整性，数据库只做存储。
我个人的建议是：不开数据库外键，而是在逻辑层维护关联关系。表里保留user_id、barber_id这些字段做逻辑关联，查询时JOIN或者多次查询都可以。这样做的好处是将来要删数据、改数据灵活得多，坏处是如果代码写得糙，可能产生“孤儿记录”。但对毕设答辩来说，你在论文里写一句“基于业务灵活性考虑，系统采用逻辑外键而非物理外键”，反而是一个可以展开讲的细节，属于加分项。
3. 后端SSM框架搭建与核心接口实现
3.1 从零搭建一个能跑的SSM骨架
很多第一次做SSM项目的朋友，在心里已经默默把这件事情划分为“地狱难度”，其实它远没有想象中那么可怕。核心是三件事：写配置、建目录、调通一个最简单的接口。
项目结构上采用Maven标准布局，Web项目打包成war包丢到Tomcat里跑。pom.xml里需要引入Spring核心、SpringMVC、MyBatis、MyBatis-Spring桥接包、MySQL驱动、Druid连接池、Jackson序列化包、JSTL依赖。这里最需要留意的是版本对齐问题，Spring的各个模块版本号必须保持一致，比如都用5.2.x，不能spring-core用5.2、spring-webmvc用5.1，否则会出现启动时莫名报NoSuchMethodError的情况，这种错误排查起来非常浪费时间。
配置上要写三个XML。applicationContext.xml负责包扫描、数据源和SqlSessionFactory的创建。springmvc.xml负责开启注解驱动、配置视图解析器和静态资源放行。MyBatis的mapper.xml则放在和mapper接口同包的位置。web.xml里配置DispatcherServlet和ContextLoaderListener的加载顺序，顺序反了会导致Spring容器初始化失败。
这里有一个几乎所有SSM新手都会撞上的经典问题：MyBatis的mapper.xml文件放在java目录下，编译后没有输出到classes目录，启动时提示Invalid bound statement (not found)。解决方式是在pom.xml的build节点里排除resources目录把xml文件也打包进去。这个坑我至少看到过几十个人踩，你自己遇到的时候别慌，改一下maven resources配置就行。
3.2 预约接口的核心逻辑：冲突检测和状态流转
预约功能是整个系统的灵魂，也是答辩时会被重点提问的部分。提交预约这个接口，前端传来的参数是userId、barberId、itemId和appointmentTime，后端要做三件事。
第一步是校验参数合法性。理发师是否存在且处于在职状态，服务项目是否存在且允许这个职级操作，预约时间是否在营业时段内。这些校验看起来不起眼，但如果漏了，后面会产生很多脏数据。
第二步是冲突检测。同一时间段（比如5月20日14:00到15:00）同一理发师不能同时服务两个顾客。实现方式不复杂，在AppointmentMapper里写一个count查询，统计同一barber_id、同一appointment_time且状态是“待确认”或“已确认”的预约条数，大于0就直接返回“该时段已被预约”。这里要注意状态过滤，已取消的订单不算冲突。
第三步是事务控制。插入预约记录前先做冲突检测，但两个请求同时到达时可能存在竞态条件。SSM里的处理方法很常规：在Service实现类上加@Transactional注解，给MySQL的表加上unique index (barber_id, appointment_time)，数据库层面兜底。双保险的好处是，即使哪天代码写漏洞了，数据库也会拒绝重复预约，至少在答辩演示时不会出现逻辑bug。
状态流转的规则要提前用业务语言想清楚。用户提交预约后状态为待确认，理发师端可以改成已确认或者取消（建议改为“已拒绝”状态，和用户主动取消区分开）。服务完成后待确认和已确认的单子都可以改为已完成。用户取消只能发生在待确认或已确认状态，已完成的订单不允许取消。这套规则看似简单，但它决定了前端按钮该在什么状态下显示，后端接口要做什么状态判断，理清之后写代码就顺畅了。
3.3 用户登录态确认与拦截器配置
预约系统里大量接口需要登录后才能调用，最直白的方案是使用Session。用户登录成功后把userId和username放到Session里，后端封装一个自定义拦截器LoginInterceptor，实现HandlerInterceptor接口，在preHandle方法里检查Session是否存在，不存在就返回401状态码，前端Axios统一拦截后跳回登录页。
某些接口还需要区分角色权限，比如后台的管理员接口和理发师接口，普通用户不能访问。做法是在拦截器里设置白名单和权限校验规则。用户登录注册、公开页面接口放行，所有以/admin开头的请求必须校验角色，所有以/user开头的请求必须校验登录状态。
补充一点关于密码加密的意见。现在新建项目如果还用纯MD5，答辩老师可能会提一句“安全性不够”。建议至少做成“MD5加盐”：注册的时候生成一个随机盐值，把盐拼在密码后面再做MD5，然后盐和密文一起存库。校验时取出盐值重新拼接计算，和密文比较。这个方案代码量只增加十几行，但答辩时提到“我对密码做了加盐处理而非明文存储”，专业感立刻不一样。
4. 前端Vue工程搭建与页面交互实现
4.1 Vue环境配置与工程初始化
Vue这个部分我从环境配置开始讲。2026年了，Vite已经是前端不可绕开的基础设施，用它创建Vue项目体验相当顺滑。命令只有一句：npm create vue@latest，然后按提示选择Router、Pinia等特性。如果电脑上Node.js版本比较老，可以先升级Node到18或20的LTS版。这里提醒一下，Vite要求Node的版本不能太低，遇到启动报错说require is not defined，基本都是版本问题而不是代码问题。
IDE方面直接用IDEA就是最常见的路线，专业版对Vue有很好的语法支持。如果你用的是社区版，装一个Vue官方插件也能凑合用。初始项目结构里src下分views、components、router、store、api这几个目录，约定从一开头就立好，后面管理几百行代码会省心很多。
前端依赖的核心只有三样：vue-router负责路由、pinia或vuex负责状态管理（用户信息放这里）、axios负责HTTP请求。Element UI按需引入就行，组件库里的表格、表单、日期选择器、弹窗这些控件做后台管理页面，基本已经等于开了外挂。
4.2 路由设计要在开始前想清楚
vue-router的配置很灵活，但也容易写乱。规划理发预约系统的路由时，我习惯把页面分成两个区域：面向顾客的网站前台和面向管理的后台。
前台路由包括：首页、发型师列表页、服务项目页、预约提交页、个人中心页、我的预约页、登录注册页。后台路由包括：管理首页看板、用户管理页、发型师管理页、项目管理页、预约管理页、统计报表页。
后台部分适合用嵌套路由，父路由是布局组件，包含侧边栏和顶栏，子路由切换时只替换内容区域。这不仅是组织结构清晰的问题，更直接关系到权限控制的实现。你可以用路由守卫在beforeEach钩子里检查用户角色，非管理员直接重定向到首页，配合后台返回的401状态码一起做双保险。
路由还有一个隐藏好处：它决定了你Vue组件页面拆分的颗粒度。一个页面一个视图组件，里面再拆小部件组件，后台上“用户管理”里那张表格就可以抽成一个复用组件，项目页面里拿来就用。好的路由设计等于帮组件划分画好了框架。
4.3 Axios封装和前端页面交互技巧
直接在前端每个组件里调用axios是不明智的，写过几次就知道，错误处理逻辑会在每个文件里重复，很丑也容易漏。建议在api目录里做一个request.js，统一创建axios实例，设置baseURL和请求拦截器、响应拦截器。
请求拦截器在每次请求前从localStorage或Pinia里取token，加到请求头的Authorization字段。响应拦截器有两个作用：如果后端返回code等于401，就强制清理登录态并跳转登录页；如果后端返回业务错误码（比如“时段冲突”），直接弹出Element UI的Message提示。这样组件里调用接口时只需要关注正常返回的数据，错误全部在拦截层面消化了，代码看起来干净清爽。
预约提交页是个典型的复杂表单，包含三个联动选择：先选理发师、再选项目、最后选时间。选理发师后项目列表要按理发师可服务范围重新拉取，选项目后时间选择器要禁用掉已经约满的时段，还可以根据项目耗时做并行时段的自动排空。这个联动逻辑放在Vue里用watch监听响应数据就很好实现。我在页面上让时间选择器disabled-date方法去检查某个日期有没有可约时段，把已经全满的日期直接置灰，用户根本不会有“选了个日期进去才发现没时间”的糟糕体验。
4.4 样式冲突的预防和“复制即用”陷阱
Vue项目里样式问题非常普遍，尤其是引入Element UI之后。3.x以前，Vue单文件组件的style默认没有作用域，如果A页面写了一个类名叫.card，B页面也写一个.card，后加载的样式会覆盖先加载的，页面表现就变得诡异。
解决办法是在style标签上加上scoped属性，或者用CSS Modules。特别要注意，如果你要从网上找现成的组件代码过来改，一眼先看它的style有没有加scoped，没有的话宁可自己重写样式也不要冒险粘进来。另外Element UI默认的主题色如果想改，可以去引入自定义变量覆盖，不要用!important去硬杠，那样改一处漏三处，血泪教训。
静态资源路径问题也很值得说一句。Vite项目构建后部署到服务器时往往不在根路径，图片和JS文件的地址会404。解决方案就是在vite.config.js里配置base: './'，这样所有资源都用相对路径引用，部署到任何子目录都不会出问题。这个问题第一次遇到时排查半小时是常态。
5. 论文撰写与答辩准备的关键路径
5.1 论文结构怎么排，每章该写多少字
很多学生程序写完了，卡在论文上，迟迟动不了笔。我的观点很明确：论文写作和写代码一样有路径，不要按章节顺序写，先写需求分析，再写系统设计，然后一次性把所有实现章节写完，最后反过来补绪论和摘要。
本科论文大致字数在1.2万到1.8万字之间。结构上通常七个章节：绪论、相关技术介绍、系统需求分析、系统设计、系统实现、系统测试、总结与展望。绪论里写背景、意义、国内外现状、论文组织结构，这一章是套话重灾区，也是最容易凑字数的地方，但建议控制在2500字以内。相关技术介绍章以Spring、SpringMVC、MyBatis、Vue、MySQL五个技术为主，每个写三百字简介加两百字“为什么选它”，不要贪多。
需求分析章节好好写用例图和用例描述。系统设计章节画好架构图、功能模块图、ER图。系统实现章节按模块逐一展开，每个模块配核心代码片段和运行截图。系统测试部分用表格列出测试用例和结果。总结加展望写自己收获了什么、系统还差什么。
这里有个建议：摘要放在最后写，因为摘要必须高度概括全文成果，你只有写完了才知道自己真的做出了什么。否则摘要不是猜的，就是事后发现和正文对不上，回头改的时候哪儿哪儿都别扭。
5.2 画图工具的坑与图表的规范
论文里最重要的三张图是用例图、架构图、ER图，这三张图直接决定了评委老师对你的第一印象。infinitely，很多同学会用draw.io画完导出成PNG，发现图片放到Word里有点糊，答辩投影后更是惨不忍睹。这里可以分享一个经验：导出时设置为矢量SVG格式，再插入Word就不会有清晰度问题。
ER图里最容易被问到的就是实体间关系。用户和预约是什么关系？预约和理发师是什么关系？理发师和服务项目又是什么关系？多对多关系需要引入关联表，但在我们这个系统里，理发师和项目之间其实是一对多：一个理发师可以擅长多个项目，一个项目可以被多个理发师服务吗？业务上通常不是。想清楚每个关系，ER图就画得清晰，答辩时被追问也说得出逻辑。
运行截图也是论文的重要组成部分。老实说，截图的作用不是为了展示效果多么炫，而是证明这个系统是真的跑起来了。给截图加图注的时候别只写“预约页面”，至少写清“预约提交页面的时段选择联动效果”，这样评阅老师能直接看出你想表达什么。截图建议统一尺寸，尽量用浏览器无痕窗口登录后截，避免带着开发测试数据或者缓存不干净的样子。
5.3 查重与降重思路：技术论文要怎么做
技术类论文的查重比文科论文好处理，因为核心内容是代码实现原理和系统设计，关键在于怎么用“自己的话”叙述。很多同学抱怨相关技术一章重复率高，大概率是因为从博客上复制了框架介绍原句，查重系统直接命中。正确做法是先理解这个技术解决了什么问题、核心机制是什么，然后关掉参考网页，用自己的语言重新组织一遍，围绕“本系统中这个技术的作用”来写。
代码片段在知网查重里会不会标红，每个学校的规则差异较大。稳妥做法是只贴最核心、最能体现设计思路的代码片段，不要大段贴完整源码。同时给每一段代码配一小段“设计意图”说明文字，比如“这里通过查询已存在预约的数量来判断时段冲突”，即使个别片段标红，篇幅影响也有限。
降重不是对付查重系统，它本质上是在检验你有没有真正理解自己做的东西。你如果理解了，就能用自己的话写出来，自然就不重复。如果完全不懂机制，只能逐字判重替换同义词，换完你会发现句子都不通顺，反而更差。
6. 实操过程中的典型问题与排查记录
6.1 开发期高频报错的定位方法
把这个系统从零到一跑通的过程，我敢保证你一定会遇到下面几个问题，而且大概率不止一次。
第一个是Spring容器启动失败，信息大概是Error creating bean with name 'sqlSessionFactory'。绝大多数原因是数据库连接配置写错了，检查一下jdbc.properties里面的url是不是写成了localhost:3306/barber_shop?serverTimezone=UTC，注意时区参数不可省略，否则MySQL 8不认。第二类原因是Druid连接池版本和MySQL驱动版本不匹配，把驱动换成8.0.x之后顺手更新Druid到1.2.x，问题基本就消停了。
第二个是POST请求后端收到的是null。先确认前端请求头Content-Type是不是application/json，再确认后端Controller参数有没有加@RequestBody。SSM项目里一个低级错误就是Controller的每个方法既不加@RequestBody也不加@RequestParam，直接一个实体类怼上去，SpringMVC拿到参数后完全没法完成映射。
第三个是跳转页404或接口404。排查思路按照“浏览器开发者工具的Network面板先看请求是否发出、再看响应状态码”的顺序来。如果请求根本没到后端，检查前端BaseURL和代理配置；如果到了后端但匹配不上，看Controller的@RequestMapping路径是不是写错了。这类问题多半是路径写错，多花一分钟看清URL再动代码，比盲目调试强得多。
第四个是中文乱码。前端正常，后端返回的数据里中文全是问号或乱码，这是SpringMVC的CharacterEncodingFilter没有配置好，或者数据库连接串里没加useUnicode=true&characterEncoding=utf8。两个位置统一配置后再加一层数据库表字段的utf8mb4，基本就有力保住了。
6.2 预约功能联调时最容易出现的业务类故障
程序层面的异常通常好解决，业务类问题才让人抓狂。第一个高发问题就是时间格式对不上。前端明明传了2026-05-20 14:30，后端接收后变成2026-05-20 02:30，先别急着调后台，往前端看数据。如果你在Vue里直接用了Date对象.toString()输出，大概率是生成的是带时区的国际标准格式，后端反序列化自动按UTC解析，就差了8小时。代码里格式化时间这一步不能省。
第二个问题是库存式的超卖，表现在两个人同时预约同一个时段，数据库里出现了两条状态为已确认的记录。这个很好解释：代码层面先查后插存在时间差，高并发下检查永远是失效的。演示时不会暴露，但如果答辩老师懂技术，问你“并发情况下如何保证不重号”，你就要把唯一索引和事务隔离级别说出来。如果你能主动提到这个并发问题以及数据库唯一索引的兜底方案，这题你就能拿到高分了。
第三个问题是测试时使用同一账号反复“预约—取消—预约”，之后发现历史取消单据越积越多。不是bug，但数据很乱。处理方式是在写死测试数据阶段，定期清理状态为已取消的预约记录，保持后台管理页面清爽。上线演示时如果后台列表塞满了垃圾数据，老师第一印象会扣分。
6.3 给学生实操作业的部署与打包建议
毕设答辩和课程设计不一样的地方在于：大多数学校要求现场演示系统，而且是在你自己准备好的电脑上。这就会遇到部署问题。后端是war包，丢到Tomcat的webapps目录下，启动完就能访问。前端Vite构建后是纯静态文件，放在Tomcat的webapps/ROOT下，或者单独用Nginx托管，让接口走代理转发到Tomcat。
如果你觉得部署到别人的机器太麻烦，退而求其次的方案是在演示环境用本地运行方式。IDEA里启动Tomcat，前端用npm run dev起Vite开发服务器，然后在Vite配置的proxy代理里把/api前缀的请求转发到http://localhost:8080。这样做的好处是改动代码即时生效，坏处是演示时前后端同时开着两个进程，稍显凌乱。
我建议至少有两天时间专门做部署演练：关掉原来的命令行窗口，抛开IDEA的调试便利，完全按生产环境的方式跑一遍完整功能，确认重启后数据还在、页面还能正常打开、预约流程不会断。很多学生在演示前夜才发现自己的项目从来没在“非开发环境”下启动过，第二天开场就翻车。提前演练省下的时间，比你熬夜排查安装问题要划算得多。
写在最后
这个项目做下来，我对“预约系统”这种题目的评价一直是：它是毕业设计里的常青树，选它不会错，但想拿高分需要一点巧劲。巧劲不在堆功能，而在把基础功能做扎实，把冲突检测、状态流转、权限控制这几个关键点讲透。具体到SSM + Vue这套组合，学习价值量很足，延展空间也在，比如后面把Spring Boot替换掉旧框架，前端换上Vite和TypeScript，数据库升级成读写分离，这些都可以作为论文展望部分的内容顺理成章写进去。根据我个人的体会，如果你能把文章里提到的这些坑都摸过一遍，在这个项目上花的时间，后面进入真实项目开发时会以更高的效率回报给你。
