又是一年毕设季，后台收到好几个读者在问“2026毕设选题怎么做”这类问题。说实话，每年看到大家抱着同一个题目到处找代码、找论文模板，我心里挺有感触的。毕设这个东西，说白了就是用四个月时间证明你具备独立完成一个小型软件项目的能力，技术栈新旧是次要的，关键是你能不能把需求拆明白、把代码写清楚、把论文写规范。
今天拿一个比较典型的课题来拆解：SSM + Vue的科技编辑及作者信息管理系统。这个题目属于典型的管理信息系统大类，业务逻辑清晰、角色分明、可扩展性强，非常适合做毕业设计。下面我把这个课题从设计思路、数据库建模、后端实现、前端页面，到论文写作和答辩准备完整拆一遍，你可以直接拿这套思路去落地，也可以根据自己的业务场景做裁剪。
1. 项目整体设计与选题价值
1.1 这个课题到底在做什么
很多同学看到“科技编辑及作者信息管理系统”这个题目，第一反应是：这不就是用户管理系统加个CRUD吗？如果你真这么想，那说明还没get到这个课题的精髓。
科技期刊的日常运作有一个非常清晰的业务链条：作者投稿 → 编辑部收稿 → 初审查重 → 送外审 → 编辑退修/录用 → 定稿排版 → 出刊。在这个链条里，至少有两个核心角色在持续产生数据：作者提交稿件、跟踪审稿进度、接收修改意见；编辑分配稿件、填写审读意见、决定稿件去向。除此之外，还有管理员负责维护系统基础数据（期刊栏目、审稿专家库、用户权限等）。
所以这个系统不是简单的“增删改查”，而是一个带状态流转的业务管理系统。它的核心价值在于：让作者和编辑在同一个平台上协作，稿件从投稿到录用每一步都有记录，谁在什么时候做了什么操作都可追溯。这才是论文里能写出“研究意义”和“创新点”的地方。
1.2 为什么选SSM + Vue这套组合
先说结论：这套技术栈不是最新的，但它是最适合本科毕设的稳妥组合。
SSM指的是Spring + SpringMVC + MyBatis三件套，在Java后端领域属于经典搭配。Spring负责Bean管理和事务控制，SpringMVC负责请求路由和参数绑定，MyBatis负责数据库操作。三个框架各管一摊，分层清晰，任何一个有经验的老师看到你的架构图都能一眼看懂，答辩时你也能讲明白“请求进来之后经过哪些层”。
前端选择Vue的理由更实际：Vue 2的生态极其成熟，Element UI组件库开箱即用，表格、表单、弹窗、分页这些管理系统的标配组件全都现成。更重要的是，Vue的响应式数据绑定和组件化开发模式，对基础一般的同学来说比直接操作DOM友好太多。前后端分离的好处是：你不需要在JSP页面里混写Java代码，前端后端可以并行开发，接口联调也更有条理。
提醒一句：如果你所在学校有明确的技术栈要求，比如必须用Spring Boot，那可以把SSM平替成Spring Boot + MyBatis Plus，整体结构和文章思路完全通用，只需替换框架配置部分的写法。
2. 数据库设计与核心表结构
2.1 核心实体梳理
动手写代码之前，先把数据模型理清楚。我习惯用“名词找实体、动词定关系”的方式来做需求分析：把题目里出现的重要名词都列出来——用户、作者、编辑、稿件、审稿意见、栏目、操作日志，然后看它们之间有什么关系。
这个系统里，最核心的实体关系是：
- 用户（User）：区分作者、编辑、管理员三种角色，一人一条记录，通过角色字段或角色表来区分权限。
- 稿件（Manuscript）：作者投稿后产生一条稿件主记录，包含标题、摘要、关键词、稿件文件路径、所属栏目、当前状态等。
- 审稿记录（Review）：编辑对稿件每次处理动作的记录，一条稿件可以有多条审稿记录，形成历史轨迹。
- 栏目/领域（Category）：期刊的栏目分类，稿件隶属于某个栏目，编辑可以按栏目筛选自己负责的稿件。
关系也很明确：一个用户可以投多篇稿件，一篇稿件属于一个作者；一篇稿件经过多个编辑处理，产生多条审稿记录；一个栏目下有多篇稿件。这就是典型的一对多和一对多模型，画ER图的时候正好用得上。
2.2 关键表结构与字段设计
表结构设计直接决定后面写代码的心情。我给这套系统设计过一版表结构，字段设计有几点值得你参考。
用户表的核心字段：用户ID、用户名、密码、真实姓名、邮箱、手机号、角色类型、注册时间、状态。密码一定要存加密后的密文，不建议用明文，答辩时老师问到安全问题也有话讲。
稿件表是整个系统的核心，字段设计要特别注意状态字段。我建议状态字段用整数或者字符串枚举，比如0=草稿、1=已投稿待分配、2=编辑初审中、3=外审中、4=退修中、5=已录用、6=已退稿。为什么不用布尔值？因为稿件状态不是一个“是/否”的问题，而是多阶段的流程节点。状态字段的意义在于：列表页筛选时一条SQL就能查“当前所有待初审的稿件”，不需要复杂的关联查询。
稿件表还需要冗余一个“当前处理编辑ID”，这个字段看起来有点违背范式，但实际查询时特别有用——编辑打开工作台，直接按处理人ID查我的待办，不需要通过审稿记录表去反查。这就是在规范化和查询性能之间做取舍，写论文的时候还可以把这种冗余设计写成“为了提升高频查询效率而做的反规范化处理”，瞬间显得有工程深度。
审稿记录表的设计要点是“只追加、不修改”。每次编辑对稿件做什么动作（分配、初审通过、退回修改、录用），都插入一条新记录，记录操作人、操作时间、意见内容、操作前的状态和操作后的状态。这个设计让整个审稿过程完全可追溯，答辩时老师问“你怎么保证操作留痕”，这就是答案。
2.3 数据字典与状态机设计
很多同学开发到一半会发现自己写的代码里面到处是魔法数字：if(status == 2)、if(status == 5)，过两个星期自己都看不懂。这个问题在稿件状态这种场景下特别突出，因为状态实在太多了。
解决思路有两个层面。代码层面，建议在后端定义一个稿件状态的常量类或者枚举类，把所有状态集中管理，比如：
public class ManuscriptStatus { public static final int DRAFT = 0; public static final int SUBMITTED = 1; public static final int UNDER_REVIEW = 2; // 其他状态... }这样写代码时语义清晰，不会出现“2到底是什么意思”这种灵魂拷问。
数据库层面，可以建一张数据字典表来维护所有状态的中文名称，前端根据字典表动态渲染状态标签。这样做的好处是：页面显示的文字可以在后台配置，不需要改代码重新部署。对于毕设来说，这一步属于“锦上添花”的功能，但确实能体现出你对系统设计的思考，论文的需求分析章节也会因此更丰满。
3. 后端核心功能实现
3.1 SSM分层架构与项目结构
SSM项目的分包结构直接照着三层架构来。我习惯这样组织：
controller：接收前端请求，做参数校验，调用service，返回JSON数据。service：业务逻辑层，处理具体业务流程，比如投稿时要把稿件信息写入、同时生成一条审稿记录、还要给编辑发送站内通知。mapper：MyBatis的数据访问层，写SQL或Mapper XML。entity/domain：实体类，对应数据库表结构。common：通用工具类、统一返回结果封装、异常处理等。
这里有一个很多新手会犯的错：把业务逻辑写在Controller里，一个接口几百行代码。这个习惯非常不好。举例说，投稿接口看起来只是插一条记录，但完整流程应该是：校验作者是否登录 → 保存稿件基本信息 → 写入稿件文件 → 生成待分配通知 → 记录操作日志。如果这些逻辑全堆在Controller里，代码可读性和可维护性都很差。正确的做法是让Controller保持单薄，只负责“接请求、调服务、返结果”，真正的业务编排放在Service层里。
3.2 登录鉴权与权限控制方案
管理系统的登录鉴权是必问的考点。我见过不少毕设用的是简单的Session判断：登录成功就把用户ID放到Session里，后续请求通过拦截器检查Session是否存在。这个方案简单易懂，缺点是跨域处理比较麻烦，前端部署在不同的端口时，Cookie和Session的维护让人头疼。
我自己做这套系统时用的是JWT（JSON Web Token）方案，整体思路是：用户登录成功后，后端生成一个Token返回给前端，前端把Token存在本地存储里，每次请求在请求头里带上Authorization: Bearer <token>，后端通过拦截器解析Token获取用户信息。
JWT方案的代码量也不大。需要一个拦截器，继承SpringMVC的HandlerInterceptor，在preHandle方法里从请求头取Token，调用工具类解析，解析失败就返回401状态码让前端跳回登录页。然后把这个拦截器注册到SpringMVC配置里，同时配置排除拦截的路径（比如登录接口、注册接口）。整个过程如果已经写熟了，半小时就能跑通。
权限控制比登录鉴权更进一步：不同角色能访问的接口不同。比如说，作者接口只能操作自己的稿件，编辑接口可以处理分配给自己的稿件，管理员接口才能操作用户管理。SpringMVC层面最直接的方案是和拦截器结合，在拦截器里取到当前用户角色后做一次判断；如果项目复杂一点可以用Spring Security的@PreAuthorize注解，但对于毕设的数据量，拦截器判断完全够用，而且更好讲清楚。
3.3 稿件管理核心流程
稿件管理是整个系统的中枢，建议优先完成投稿、审稿、退修三个核心流程，再做其余功能。
投稿流程的关键点在于文件上传。科技期刊投稿时作者通常要提交论文全文（PDF或Word）。文件上传这块我用的是本地存储，上传时把文件保存在服务器指定目录下，文件名用UUID重命名防止冲突，再把文件原始名称和存储路径一起写进稿件表。这里要注意：数据库里保存的应该是相对路径，而不是绝对路径，这样项目部署时换个服务器目录也不需要修改数据库数据。
审稿流程的关键点在于状态流转正确性。比如编辑提交初审结果时，如果选择“通过”，稿件状态应该从“待初审”变成“外审中”；如果选择“退回修改”，状态应该变成“退修中”。这种逻辑很容易在状态多的时候搞混。我给每个流程节点都画了状态流转图：作者能提交的状态变更、编辑能提交的状态变更、管理员的特殊操作，各自形成闭环。代码实现时不建议用复杂的if-else嵌套，而是每种场景写成独立的方法——submitManuscript()、firstReview()、acceptManuscript()、rejectManuscript()——方法名称直接对应业务动作，调用关系一目了然。
3.4 列表查询与分页优化
管理系统最常写的接口就是分页列表。作者端要“我的稿件列表”，编辑端要“按栏目筛选的待审列表”，管理员要“所有用户列表”。这些接口的共性是一个动态条件的分页查询。
MyBatis里做分页查询有两个选择：一个是手写LIMIT #{offset}, #{pageSize}，自己算偏移量，然后另写一个count查询来拿总数；另一个是使用PageHelper插件，对Mapper查询自动拦截生成分页SQL。
我比较推荐PageHelper，理由有两个：一是少写很多样板代码，二是它生成的count和分页SQL是自动的，不太容易出错。但使用PageHelper有一个细节必须注意：分页插件只对紧接着的第一个查询生效，如果你在同一个Mapper方法里先做了其他查询，再查列表数据，分页就会失效或者作用到错误的查询上。这个坑我踩过一次，排查了半天才发现是查询顺序的问题。
还有一个优化细节：列表页如果只显示稿件的标题、作者名、状态、提交时间，就不要在SQL里把摘要、关键词、文件路径这些大字段查出来。这样做对一张几百条数据的表来说优化效果不明显，但能养成好的查询习惯，而且也是论文里“系统优化”部分可以写的点。
3.5 事务控制与异常处理
投稿这个操作涉及多张表写入：稿件表插入一条记录，审稿记录表插入一条初始化记录，可能还要更新作者的投稿统计数据。这三步操作任何一个失败，前面的写入都必须回滚，否则就会出现“稿件没插进去但审稿记录有残留”这种脏数据。Spring的@Transactional注解就是干这个的，在Service方法上加上注解，Spring容器会自动管理事务边界，方法内任何一个RuntimeException都会触发回滚。
异常处理建议做一个全局异常处理器，用@ControllerAdvice注解标一个类，定义统一的异常处理逻辑。业务上可以自定义一个BusinessException，在需要中断业务流程的地方主动抛出；全局异常处理器捕获后返回给前端一个统一的错误格式：状态码、提示信息、具体错误详情。这样可以避免出现“数据库异常堆栈直接返回给前端”这种既危险又不友好的情况。我在开发时还遇到过一个情况：文件上传成功但数据库写入失败，这时候需要手动删除已经上传的文件，否则会出现“孤儿文件”占用服务器磁盘。这个细节在代码里用try-catch包住后续操作，异常时在catch块中调用文件删除方法。
4. 前端Vue页面设计与功能实现
4.1 前端工程化结构与路由设计
前端工程建议用Vue CLI创建项目，并按要求勾选Router、Vuex、Axios这些插件。初始创建完项目后，第一件事是装Element UI组件库和封装自己的目录结构。
我的习惯是这样的目录结构：
views：按角色分模块，views/author放作者端页面，views/editor放编辑端页面，views/admin放管理员页面。components：放公共组件，比如数据字典状态标签、文件上传组件、分页组件。api：按业务模块放后端接口的封装文件。router：路由配置，所有页面都在这里注册。utils：axios实例封装、Token存取工具等。
路由设计要给三种角色设计不同的首页和导航菜单。作者进来看到的是“我的投稿”和“新建投稿”；编辑看到的是“待办审稿”和“稿件管理”；管理员看到的是“用户管理”“栏目管理”“系统日志”。这里的实现方案是前端做动态路由或路由守卫：用户登录后根据角色字段决定能访问哪些路由，不能访问的页面通过router.beforeEach拦截并重定向到登录页。
4.2 核心页面解析
作者中心的“新建投稿”页面是整个系统里表单最复杂的页面。要收集的信息包括：稿件标题、摘要、关键词、所属栏目、稿件文件上传。这里有两个细节值得注意：文件上传后要拿后端返回的文件存储路径填充到表单的隐藏字段里，提交时随表单数据一起发送；如果作者在填写过程中选择了“保存草稿”，需要把当前未提交的表单数据暂存到后端，相当于稿件的“草稿状态”。这个功能做起来不复杂，但在论文的“功能模块设计”里却是一个亮点，因为大部分同类系统都不太在意草稿细节。
编辑工作台的列表页设计思路是：顶部放一个筛选区域，按栏目、按稿件状态、按时间范围过滤；下方是表格，展示稿件基本信息；右侧放操作按钮——查看详情、进入审稿、填写意见。稿件详情页要能够预览作者上传的稿件文件，这一块用了浏览器内置的PDF预览能力，前端用<iframe>标签加载后端返回的文件地址就行，如果是Word文件就提示下载后查看，省去在线预览的复杂度。
系统管理页中的用户管理跟普通管理系统的用户管理差不多，但有一个特殊业务点：管理员可以创建“编辑”账号并分配负责的栏目。这里就涉及用户表和栏目表之间的关联了。最简单的实现是在用户表加一个category_id字段，表示这个编辑负责哪个栏目。这样做数据模型简单，但不够灵活；如果将来一个编辑负责多个栏目，就得用中间表。毕设的话，建议直接用中间表，关联查询也不算复杂，论文中还能写一句“支持编辑与栏目的多对多分配，具备更好的扩展性”，在答辩时就是一个可以主动提到的小亮点。
4.3 Axios请求封装与权限路由拦截
前端所有请求建议统一走封装好的axios实例。我在utils/request.js里创建axios实例时配置了baseURL指向后端接口地址，然后在请求拦截器里从本地存储取出Token并添加到请求头。响应拦截器里做两件关键的事：第一，当HTTP状态码是401时，清掉本地Token并跳转登录页；第二，当后端的业务状态码表示“未登录”或“Token过期”时，同样做跳转处理。
这个封装的逻辑看起来很简单，却是我强烈建议你花时间做好的。因为一旦前端没有统一的Token处理逻辑，每个页面都要自己判断登录状态，代码会出现大量重复，还会出现“明明Token过期了却还在调接口导致一直报错”的低级问题。
路由守卫这一块，我用router.beforeEach统一做三件事：判断用户是否已登录、判断当前路由是否在允许访问的列表里、记录用户来源方便登录后跳回。如果用户没登录就想访问系统的内部页面，直接跳回登录页，并且把目标路由用query参数传递，登录成功后跳回去，这个小细节的体验提升非常明显。
5. 论文结构规划与写作要点
5.1 论文题目与章节框架设计
论文题目不必跟系统名称一模一样，可以稍作修饰，比如“基于SSM与Vue的科技编辑及作者信息管理系统的设计与实现”。这种题目是毕设论文的标准句式，直白地交代了技术路线和功能范围，没有歧义。
论文的章节建议按经典的“六章结构”组织。第一章绪论写研究背景、意义、国内外管理信息系统的发展现状和主要工作；第二章相关技术介绍，写SSM框架的原理、Vue前端框架特点、MySQL数据库、前后端分离架构；第三章需求分析，写可行性分析、功能需求、用例图、非功能需求；第四章系统设计，写总体架构、功能模块设计、数据库设计；第五章系统实现，写核心模块的界面截图和关键代码；第六章系统测试，写测试环境、测试用例、测试结果。
5.2 核心章节的写法与常见误区
需求分析章节最大的坑是“把用例图画完就结束”。用例图只是需求表达的一种方式，你还得配合文字说明每个功能模块的业务流程。比如投稿流程：作者登录 → 填写稿件信息 → 上传文件 → 确认提交 → 系统记录投稿时间 → 编辑端工作台出现新稿件待办。用文字一步步把这个流程描述清楚，配合用例图和活动图，需求分析部分才算是真正写透了。
系统设计章节数据库设计是重点，需要给出完整的ER图和数据表结构。每张表要列清楚字段名、类型、约束、说明。这里的常见问题是表结构字段名和代码里的实体类属性名对不上，或者说明写得太简略。建议在写论文之前，先把数据库的表结构文档整理好，做到字段和实体类一一对应，写起论文来就很顺畅。
系统实现章节要注意图文结合和详略得当。页面功能截图配文字说明，关键代码配核心逻辑分析。不要把所有代码都贴到论文里——论文不是代码清单，而是展示你“如何解决问题”的思路。比如一个状态流转的代码，你可以只贴核心判断逻辑那段，然后用文字说明状态流转的完整规则。
系统测试章节不要只写“测试结果通过”就完事。给出具体的测试用例表：测试模块、测试步骤、预期结果、实际结果。举例来说，测试“作者提交退修稿件”这个功能，测试步骤是：作者登录 → 进入退修中列表 → 点击上传修改稿 → 填写回复说明 → 提交 → 编辑端刷新看到退修稿到达待审列表。预期结果是状态变成“待重审”，实际结果与预期一致。这样的测试用例才有说服力。
5.3 答辩准备与高频问题应对
答辩环节老师的提问基本集中在“为什么用这个技术”“系统的核心功能怎么实现”“有没有考虑某些特殊情况”“你自己做了什么”。
“SSM和Spring Boot有什么区别，为什么选SSM”这个问题几乎必被问到，你要准备一个说得通的答案，可以从“学校课程以SSM教学为主、对底层原理理解更深入”角度回答，也补充说明SSM的三层架构更有利于展示框架整合能力。但注意，不要贬低Spring Boot，把它说成“开发效率高但封装太多，不利于理解底层”即可，这样显得理性客观。
稿件状态流转这块的问题，老师可能会问：“如果编辑在初审时误操作把稿件退稿了，还能恢复吗？”答案应该围绕审稿记录表的设计来展开：每次操作都写入审稿记录，保留操作前后状态，可以通过审稿记录把状态改回去。这个回答充分体现了你系统设计上的考虑，比“没有这个功能”好太多。
还有一个容易被追问的点是“系统安全性”。密码加密、Token过期管理、文件上传的危险性过滤（限制扩展名、重命名存储）都是可以展开说的。如果老师追问得深了，比如“上传文件中包含恶意脚本怎么办”，你可以坦诚说明“上传文件只做存储和下载，不做在线解析HTML，所以脚本不会在系统内执行”，这个解释是站得住脚的。
6. 开发过程中的常见坑与避坑技巧
6.1 环境配置阶段的坑
JDK版本问题排在第一位。SSM框架传统的依赖配置是用JDK 8编译的，如果机器上装的是JDK 17或更高版本，启动Tomcat大概率报错，错误信息看着像是各种奇怪的ClassNotFoundException，但根因其实是版本兼容。建议：不要追求高版本JDK，老老实实装JDK 8，Maven配置文件里的source和target都设为1.8，整个团队保持一致。
Maven依赖冲突也很常见。比如项目里同时引入了多个版本的依赖，某些间接依赖因为传递关系被重复引入，导致启动时报冲突。在pom.xml里把冲突出现频率最高的那组依赖用<exclusions>排除掉。这个操作说起来简单，但找到底是哪组冲突花了我不止一次时间。建议一开始就建一个依赖清单，明确每个依赖的版本，spring-webmvc、spring-jdbc、mybatis-spring版本尽量保持匹配，别混着用不同大版本的依赖。
MySQL的时区问题在连接数据库时就会遇到。配置jdbc连接串时加上serverTimezone=Asia/Shanghai，否则插入时间字段会提示错误或者存进去的时间比正常时间差8小时。这个错很隐蔽，数据看着能存能查，就是时间不对，排查方向容易走偏。
6.2 前后端联调阶段的坑
跨域问题几乎是前后端分离项目第一次联调时必然碰到的。前端跑在开发服务器比如8080端口，后端跑在Tomcat的8080端口的话还好说，但如果后端端口没改，直接冲突；如果后端用的是9090之类不同的端口，前端axios请求时就会因为跨域策略被浏览器拦截。解决方案有三种：后端配置跨域过滤器、前端配置代理、或者干脆开发时不走浏览器直接测试接口。最理想的是后端的跨域配置，代码量大概十行左右，写在SpringMVC配置里允许所有来源即可，毕业设计阶段不需要做太严格的跨域白名单。
Token过期问题在联调时也常遇到。开发阶段Token过期时间放到2小时以上，省得写代码写到一半突然被踢下线。到系统完善阶段再把过期时间调短测试过期逻辑。另外一个细节是：后端拦截器对OPTIONS请求必须放行，否则前端发预检请求时直接被拦截，请求永远到达不了Controller，浏览器控制台报的错让你完全摸不着头脑。这个坑我调试了很久才意识到，顺手记录下来，后来每次搭前后端分离项目都先把OPTIONS请求处理写好。
6.3 时间规划与节奏控制
毕设开发最怕的不是技术难点，而是时间管理失控。我建议按三个阶段推进：第一阶段花一周做需求分析和数据库设计，把全部表结构定下来；第二阶段花三周做后端接口，这一阶段纯后端开发，前端只用Postman测接口；第三阶段花两周做前端页面和联调。这个节奏确保你在开发中期就能拿出可演示的后端接口，而不是到最后一两周发现前后端根本连通不了。
还有一个比较现实的经验：开发过程中随时把功能截图和代码片段保存好。写论文的时候，实现章节需要的截图、核心逻辑代码，如果你边开发边积累素材，最后汇总时至少能节省两三天时间。我见过太多同学开发阶段风风火火地跑通了所有功能，到论文阶段还得重新构造数据、反复截图补素材，非常浪费时间。
6.4 提升答辩印象分的几个细节
除了程序的健壮性，答辩时的印象分也很重要。有两处细节值得做：一是给系统加一个简单的仪表盘首页，展示待处理稿件数量、近七天投稿趋势、各栏目稿件分布一类的统计图表。技术上用Vue配一个图表库就能实现，不复杂，但成品演示的“高级感”一下子就有差别了。
二是把项目部署到服务器上，哪怕只是一台本地虚拟机或云服务器。当答辩时老师问“系统能实际运行吗”，你直接说“系统已经部署在某服务器上”比现场启动开发环境要可靠得多。具体做法就是用Tomcat把后端打成War包启动，前端用npm run build打包成静态文件，交给Nginx托管。这一步不算难，网上教程一大把，但三十个毕设里也就两三个人做了，做了就是差异。
写在最后
我做这套系统的过程中最深的体会是：技术本身解决的是“怎么做”的问题，但要做好一个毕设，先想清楚的是“为什么这么做”。数据库为什么这样设计、状态流转为什么选择这个模型、前端为什么封装统一的请求层，每一个决定背后都要有理由。当你在准备答辩时把这些理由整理清楚，你会发现论文很好写，老师提问也接得住。
如果你现在正在做这套SSM + Vue的系统，有几个建议给到你：第一，不要为了“看起来高级”而过早引入自己完全不会用的技术，毕业设计的核心是完整性和自洽性；第二，代码不一定最优雅，但一定要是自己能讲清楚的；第三，好好利用版本管理工具，每天提交一次代码，出了问题能回退，也方便回头看自己的开发过程。祝一切顺利。
