又到毕设季每年这个时候我都能在各类技术社区里看到同一条高频求助“ssmvue旅游管理系统论文程序”。说实话这个选题被选中不是没有道理——SSM是很多高校Java课程还在采用的经典组合Vue又是企业里主流的渐进式前端框架旅游管理系统的业务量级也刚好卡在“能写东西”和“不会太失控”之间。如果你也是2026届的准毕业生或者刚接手类似的全栈项目这篇内容就是照着“从零到一做完并写出论文”的完整路线来拆的。我会先讲清楚为什么这个选题适合当毕设再从数据库设计、后端落地、前端联调一路走到论文撰写和答辩准备最后把我自己踩过的坑和排错思路一并放出来。整个项目做下来你要的不是一个能跑通的Demo而是一套能支撑你回答评委追问的完整逻辑以及可以交付的论文与程序两份成果。1. 为什么旅游管理系统适合作为SSMVue的毕设选题1.1 业务复杂度“刚刚好”的选题逻辑毕业设计的选题最怕两个极端一是纯增删改查比如简单的用户信息管理做完之后评阅老师会觉得工作量不足答辩时也很难聊出深度二是过于庞大比如带分布式微服务、高并发秒杀的内容学生一个人根本驾驭不了最后交付的东西大概率是拼凑的。旅游管理系统恰好落在中间。它涉及游客浏览景点、用户注册登录、线路下单、订单状态流转、后台数据维护等多个环节既有典型的多表关联查询订单关联用户和线路也有条件搜索、分页列表、状态更新这种“企业里每天都在写”的功能。加上收藏、评论、统计这些可以灵活扩展的模块工作量既够一篇本科毕设展开又不会让人写到崩溃。无论是SSM后端还是Vue前端都能在这个业务场景里找到合适的表达空间。你去看大量已有的毕设选题库旅游、酒店、图书、商品管理这类“经典业务Web系统”的题目经久不衰本质就是因为这类系统在业务流程上天然完整评委看得懂学生也讲得清。换一个冷门领域反而容易出问题你自己都说不清楚业务规则设计出来的表也会漏洞百出。1.2 SSMVue前后端分离为什么经得起答辩追问先明确一个事实市面上确实有大量旅游管理系统用Spring Boot代替SSM但既然题目明确写了SSMVue那就要按这套组合来准备。SSM全称是Spring、SpringMVC、MyBatis三个框架的整合。Spring负责对象管理和依赖注入SpringMVC负责接收HTTP请求并分发到ControllerMyBatis负责把SQL语句和Java方法对应起来。三者各管一段边界清晰面试官或评委如果往深里问“你们每个框架各自干什么”“Bean的生命周期”“Mapper接口为什么没有实现类也能调用”你都有对应的知识储备可以讲。Vue端采用前后端分离开发后页面和数据是分开走的Vue组件只负责渲染数据通过Axios从后端接口获取。这种模式的好处是前端开发和后端开发可以并行出问题时定位也清楚页面白屏大概率是前端路由或数据字段问题接口报错则是后端逻辑问题。评委问一句“你的系统怎么和数据库交互”你可以从头到尾把这条链路说完整这本身就是加分项。2. 需求拆解与数据库设计把业务变成可落地的表2.1 角色、功能模块与页面清单动手写代码前先把角色和功能边界画清楚。这个系统我建议分三类角色游客、注册用户、管理员。游客能做的事最少主要是浏览首页、看景点列表和详情、搜索线路不需要登录。注册用户在此基础上多出四件事下单预订旅游线路、对已完成的订单发表评论、收藏喜欢的景点或线路、在个人中心管理自己的订单。管理员则是整个系统的维护者管理景点信息、旅游线路、酒店资源、订单状态、用户账号以及查看一些简单的业务统计。把这个需求翻译成前端页面就是如下这些门户端首页、景点列表、景点详情、线路列表、线路详情、酒店列表、登录注册、个人中心、下单页后台管理端登录、仪表盘、景点管理、线路管理、酒店管理、订单管理、用户管理、评论管理。功能模块不用贪多把上面每一块做成可用的状态工作量已经足够一篇论文了。多出来的时间不如花在把某一两个模块做得更深比如订单状态流转和搜索排序。2.2 核心数据表设计思路数据库是整个系统的地基表设计不好后面所有代码都在还债。我按实际项目里最常用的方式给出核心表一共七张左右用户表sys_user用户ID、用户名、密码、昵称、手机号、头像、角色、创建时间。景点表scenic_spot景点ID、名称、简介、详细描述、图片地址、所在地区、门票价格、开放时间、创建时间。旅游线路表travel_line线路ID、线路名称、所属景点ID、出发城市、目的地、行程天数、价格、线路介绍、封面图、上架状态。酒店表hotel酒店ID、名称、地址、星级、价格区间、图片、联系方式、简介。订单表orders订单ID、订单编号、用户ID、线路ID、酒店ID、出行人数、总金额、联系人、手机号、状态、下单时间、支付时间。收藏表favorite收藏ID、用户ID、线路ID、收藏时间也可以做景点收藏再加一个类型字段。评论表comment评论ID、用户ID、线路ID、评分、评论内容、评论时间。以订单表为例SQL大概长这样CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键, order_no varchar(32) NOT NULL COMMENT 订单编号, user_id bigint(20) NOT NULL COMMENT 下单用户ID, line_id bigint(20) DEFAULT NULL COMMENT 旅游线路ID, hotel_id bigint(20) DEFAULT NULL COMMENT 酒店ID, travel_date date DEFAULT NULL COMMENT 出行日期, people_count int(11) DEFAULT 1 COMMENT 出行人数, total_amount decimal(10,2) NOT NULL COMMENT 总金额, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 订单状态0待支付 1已支付 2已取消 3已退款 4已完成, contact_name varchar(50) DEFAULT NULL COMMENT 联系人, contact_phone varchar(20) DEFAULT NULL COMMENT 联系电话, create_time datetime DEFAULT NULL COMMENT 下单时间, pay_time datetime DEFAULT NULL COMMENT 支付时间, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;有两个设计细节值得说明。第一金额字段必须用decimal绝不能用double或float浮点数在累计和比较时会出现精度问题这在答辩时是一个很专业的讨论点。第二订单编号做成唯一字符串而不是直接用自增ID暴露给用户一方面看起来规范另一方面避免别人通过改ID遍历所有订单。2.3 订单状态机的设计一个int字段撑起完整流程订单模块是旅游管理系统里最有“含金量”的地方因为它是唯一的流程性业务。我的建议是只用status一个字段配合代码里的常量或枚举类来表示订单生命周期。按最常见的流程走用户提交订单后状态为0待支付调用模拟支付接口后变成1已支付支付后到出行日期结束可以变成4已完成。如果用户在支付前取消则变为2已取消如果这是支付后的退款场景则变为3已退款。更新状态时不要先查出来再比对再更新直接用一条带条件的UPDATE去做状态流转比如“待支付转已支付”写成UPDATE orders SET status 1, pay_time NOW() WHERE id ? AND status 0这样可以避免并发环境下重复支付的问题。我当时给这个项目写了一个OrderStatusEnum把每个状态的中文名、编码、前置状态都放在枚举里所有状态流转都走一个统一的Service方法。后面做论文测试表格时每个用例直接对着枚举核对省了很多时间。3. 后端骨架搭建SSM三层的整合顺序与易错点3.1 Maven工程结构与分层原则先说我推荐的工程目录结构。用Maven构建打包方式打成war包整体结构如下travel-system ├── pom.xml └── src └── main ├── java │ └── com │ └── travel │ ├── controller # 接口层 │ ├── service # 业务层 │ │ ├── impl │ │ └── interface │ ├── mapper # MyBatis的Mapper接口 │ ├── entity # 数据库实体类 │ ├── dto # 前端传输对象 │ ├── common # 统一返回结果、常量、异常 │ └── config # 配置类 └── resources ├── mapper # MyBatis的XML文件 ├── spring │ ├── applicationContext.xml │ └── spring-mvc.xml ├── jdbc.properties └── mybatis-config.xml分层逻辑很简单Controller只做参数接收和结果包装不写业务代码Service层处理业务规则和事务Mapper只做数据库操作。我见过很多学生把查询逻辑直接写在Controller里一开始写起来很快一旦功能变多就会变成一个大泥球。分层的好处是每个方法都能独立测试出了问题也能快速定位这在你写论文的“系统测试”章节时会非常省力。3.2 配置三件套依赖、数据源与事务SSM项目最烦人的地方就是配置文件多。pom.xml里要把spring-webmvc、spring-jdbc、mybatis、mybatis-spring、mysql驱动、druid连接池、lombok等依赖都引进来还要注意版本之间的兼容关系。比如Spring 5.3.x版本搭配mybatis-spring 2.0.x基本没问题太高或太低都可能出现莫名其妙的报错。我建议第一次搭建时直接锁定一组经过验证的版本组合别追最新版。数据源我用的是Druid连接池在jdbc.properties里配置数据库连接信息。这里有一个非常容易踩的坑如果数据库是MySQL 8.x驱动类是com.mysql.cj.jdbc.Driver而且连接URL上面一定要加时区参数serverTimezoneAsia/Shanghai否则启动时直接给你抛一个空指针或时区错误。Spring配置我拆成两个文件来管根容器applicationContext.xml管数据源、事务、MyBatis的Mapper扫描spring-mvc.xml只扫描Controller开启注解驱动和静态资源映射。这样区分是SSM的老传统避免重复扫描Bean导致事务失效。事务是另一个高频问题。业务方法上要用Transactional并且放在Service实现类上而不是Controller上。事务只在Service层有意义因为Controller只是入口真正操作数据库的链条在Service里。比如用户下单这个动作需要同时插入一条订单记录、扣减线路的库存或余位如果第二步失败第一步也不能保留这时候事务就要包住整个方法。3.3 MyBatis Mapper最容易被问到的动态SQLMyBatis的核心是Mapper接口加XML文件。接口里定义方法XML里写SQL用namespace绑定。实际开发中景点列表这类页面很少是简单查询往往要同时支持线路名称模糊搜索、地区筛选、价格升降序排序、分页。这时候动态SQL就是省力神器。以带条件的景点查询为例select idselectScenicList resultTypecom.travel.entity.ScenicSpot SELECT * FROM scenic_spot where if testname ! null and name ! AND name LIKE CONCAT(%, #{name}, %) /if if testregion ! null and region ! AND region #{region} /if if testminPrice ! null AND ticket_price gt; #{minPrice} /if /where ORDER BY choose when testorderBy priceAscticket_price ASC/when when testorderBy priceDescticket_price DESC/when otherwisecreate_time DESC/otherwise /choose LIMIT #{offset}, #{pageSize} /select注意几个细节where标签会自动处理第一个条件前面的AND比手动加WHERE 11干净得多排序字段不能直接拼接用户输入不然有SQL注入风险我用choose把它限制在几个白名单值里分页直接写在SQL里没有引入PageHelper这样对新手理解更直观。当你用SSM做毕设时评阅老师大概率会问你MyBatis的#{}和${}有什么区别。答案就是#{}是预编译参数占位符能防注入${}是字符串拼接有注入风险只能用在表名、排序字段等无法用占位符的地方并且必须自己做校验。3.4 从Controller到Mapper的一次完整请求链路我用用户下单功能把整条链路串起来。Controller负责接收参数并返回统一结果RestController RequestMapping(/api/order) public class OrderController { Resource private OrderService orderService; PostMapping(/create) public Result createOrder(RequestBody OrderCreateDTO dto) { // 参数校验放在Service里更合适Controller只做转发 OrderVO vo orderService.createOrder(dto); return Result.success(vo); } }Service层负责业务处理检查线路是否存在、是否上架计算总金额生成唯一订单号最后把数据写到数据库。关键的方法签名大致是这样Override Transactional(rollbackFor Exception.class) public OrderVO createOrder(OrderCreateDTO dto) { // 1. 根据dto.getLineId()查询线路为空或下架则抛业务异常 // 2. 计算 totalAmount line.price * peopleCount (hotel可加可不加) // 3. 生成订单编号比如时间戳随机数 // 4. 组装Orders实体status设为0 // 5. orderMapper.insert(order) // 6. 返回给前端包含订单id和金额等待支付 }Mapper接口就一行int insert(Orders order);对应的XML里用useGeneratedKeystrue keyPropertyid把数据库自增主键回填到实体上。这样做的好处是订单创建成功后前端马上要用订单ID去调用支付接口不需要再查一遍。4. 前端Vue页面与接口联调从静态页面到数据驱动的切换4.1 前端项目组织与路由规划Vue这边我用Vue CLI创建项目配合Vue Router做页面路由Axios发请求UI组件库选一个成熟的桌面端组件库后端管理页面靠它能省一大半工作量。前端目录结构我习惯这样组织src ├── api # 接口请求统一封装 ├── assets # 静态资源 ├── components # 公共组件分页、图片上传等 ├── router # 路由配置 ├── store # 状态管理Vuex/Pinia ├── views # 页面组件 │ ├── home # 门户端页面 │ └── admin # 管理端页面 ├── App.vue └── main.js路由规划直接用两张表来记门户端有/首页、/scenic景点列表、/scenic/:id景点详情、/line线路列表、/line/:id线路详情、/login、/register、/user/order个人订单后台端统一挂在/admin下面子路由是dashboard、scenicManage、orderManage、userManage等。管理端页面要根据登录用户的角色做路由守卫没登录或不是管理员一律拦截到登录页这一步是答辩时常被问到的“权限控制”实现点。4.2 统一返回结果与Axios封装后端和前端约定好“对话格式”前后端分离开发最怕接口返回格式五花八门。所以我一开始就定好后端统一返回结构public class Result { private Integer code; // 200成功500失败401未登录 private String message; private Object data; // 静态方法 success( data ) 和 error( msg ) }前端封装Axios时所有请求都走同一个实例。我在request.js里做了三件事设置基础URL请求拦截器里从本地存储取出Token并塞到Header响应拦截器里统一处理code。code不是200时直接弹出错误提示401时跳回登录页。import axios from axios import { Message } from element-ui const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] token } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 200) { Message.error(res.message || 请求失败) if (res.code 401) { router.push(/login) } return Promise.reject(new Error(res.message)) } return res }, error { Message.error(网络异常请稍后重试) return Promise.reject(error) } )这套约定的好处是后面写每个页面时只管调用接口拿数据、渲染数据不用每处都重复写错误提示。论文的“系统实现”章节里你也可以截这个文件作为前后端交互设计的例子。4.3 重点页面实现逻辑列表、详情、下单、后台表格拿景点列表页做例子。这个页面要支持搜索、分页和排序。我在页面里维护一个queryParams对象data() { return { queryParams: { pageNum: 1, pageSize: 8, name: , region: , orderBy: }, total: 0, list: [] } }, methods: { async fetchList() { const res await request.get(/scenic/page, { params: this.queryParams }) this.list res.data.records this.total res.data.total }, handleSearch() { this.queryParams.pageNum 1 this.fetchList() } }列表渲染就是简单的v-for每个卡片右上角给一个“收藏”按钮。收藏按钮是前后端联动的典型场景未登录点击时判断Token没有就跳登录页已登录就调用收藏接口再把按钮状态从“未收藏”切换成“已收藏”。下单页需要注意数据的回显和不可随意修改。用户在页面里选择线路后金额、线路名称这些字段应该由后端返回前端只展示用户能修改的是出行人数和联系人信息。提交订单后进入“待支付”状态前端弹一个模拟支付的对话框调用支付接口后刷新订单状态。整个流程你在论文里要配两张截图一张是下单前页面一张是支付成功后的订单列表评委对“这个系统确实能跑通完整业务”的印象基本就靠这两张图建立起来。后台管理页面相对机械一套“表格弹窗表单删除确认”可以复制到所有管理模块。稍微需要花点心思的是景点图片上传我的处理方式是把图片传到服务器某个静态目录下后端接口返回可访问的图片URL前端用这个URL渲染。开发环境还要在SpringMVC配置里加上资源映射否则上传成功但浏览器显示不出来。4.4 前后端联调中常见的三个问题第一个是跨域。前后端分离开发时前端跑在8080端口后端跑在8081端口浏览器会拦截跨域请求。解决方式是在后端加一个全局CorsFilter放行指定来源和请求头。别只在某个Controller上加CrossOrigin那样每个接口都要加一遍而且容易漏。第二个是日期格式化。Java后端返回LocalDateTime时默认序列化出来的格式是一长串数字前端没法直接显示。处理方式是在后端全局配置Jackson的日期格式或者给实体字段加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)。前端展示时再用Dayjs做二次处理保证列表页和详情页的显示一致。第三个是长整型精度问题。数据库主键是bigint传到前端后JS的Number类型超过一定位数会丢失精度。像订单ID这种19位长度的数字直接从接口取来再用会变成不精确的值。我的解决方法是统一在实体类的ID字段上使用JsonSerialize(using ToStringSerializer.class)把ID转成字符串传给前端。这个细节非常小众但一旦踩中会让你排查很久写进论文的“问题与解决”部分反而能体现你真的调过Bug。5. 论文写作路线程序跑通后再动笔顺序反而更顺5.1 论文目录怎么搭很多同学把写论文想得很可怕其实毕设论文有一套非常固定的结构。我的建议是采用下面的目录框架二级三级标题按实际内容微调摘要含关键词第一章 绪论研究背景与意义、国内外研究现状、主要工作内容第二章 相关技术介绍SSM框架、Vue框架、MySQL、开发工具第三章 系统分析可行性分析、功能需求分析、非功能需求分析、用例分析第四章 系统设计总体架构设计、功能模块设计、数据库设计含E-R图和表结构第五章 系统实现分门户端和管理端按功能模块逐块给出页面截图和核心代码说明第六章 系统测试测试目的与环境、功能测试用例、性能测试、测试结论第七章 总结与展望参考文献、致谢写的时候要注意不是程序做完才写论文而是程序做到一半就可以开始写前两章。绪论和相关技术这两章跟代码无关完全可以先写需求分析在表结构设计时就已经清晰了系统设计和数据库设计基本是“程序反过来翻译成文字”。真正依赖代码完成的是第五章系统实现需要至少是主体功能做完、截图能展示状态时才能动笔。5.2 从程序倒推需求分析与设计图画图是论文里最耗时的部分但如果你已经写完了程序和数据库其实所有的图都是“把已有结构画出来”。用例图就是把功能模块表换成UML的表达形式一个功能写一个用例E-R图就是把表之间的外键关系画出来用户和订单是一对多线路和订单是一对多用户和收藏是一对多流程图最值得画的是订单状态的流转图把0到1到4的转移画清楚就行。这里有一个我强烈建议的做法在系统设计章节放一张功能结构图在介绍每个功能时正文里先写“本功能包含查询条件、表格展示、新增删除操作”再配一行代码和一个页面截图。所有图表尽量在Visio或绘图工具里做统一的配色和线条不要表格里截一张、流程图里又是另一个风格论文整体的专业感会因此提升一大截。5.3 系统测试章节不是凑字数功能测试用例表怎么写测试章节常被学生当成水字数的重点区域但评委其实很看重测试用例是不是真的可执行。我给一个直接用得上的表格模板测试编号测试模块测试步骤预期结果实际结果是否通过TC-001用户登录输入正确用户名密码点击登录登录成功跳转首页登录成功并跳转通过TC-002用户登录输入错误密码提示密码错误提示密码错误通过TC-003线路查询关键词搜索含“成都”的线路显示全部包含“成都”的结果结果正确通过TC-004线路详情点击线路卡片进入详情出现简介、价格、评论页面正常显示通过TC-005创建订单选择线路填写人数并提交生成待支付订单订单列表出现待支付记录通过TC-006模拟支付点击支付并确认订单状态变为已支付状态更新正确通过TC-007评论对已完成订单发表评论评论出现在线路详情页评论展示正常通过论文撰写时这类用例表放十几条就够了不用把所有边界条件列全但一定要覆盖每个核心模块。另外再补一段性能测试描述我用压测工具对一个接口做了50个并发连续调用得到的平均响应时间在某个合理范围内据此得出“系统满足轻量级访问需求”的结论。这个测试不需要做得多么深入但它的存在会让论文的结构完整很多。5.4 答辩高频提问与回答思路答辩不是比谁代码写得多而是比谁能把做的东西讲清楚。我梳理了五个必问问题建议对着镜子练两遍。第一问“你的系统是做什么的面向谁”——用一句话说清楚是旅游信息门户加后台管理用户能浏览线路并下单管理员能维护系统和处理订单。第二问“SSM三个框架分别干了什么”——Spring管对象SpringMVC管请求分发MyBatis管数据库访问。如果能再补一句“三者通过Spring的IOC容器整合在一起”就足够专业。第三问“为什么用Vue不用传统JSP”——答前后端分离、组件复用、开发效率更高数据通过接口交互这是前端开发的趋势。第四问“数据库表之间是什么关系”——把用户、订单、线路、收藏表之间的联系讲出来顺手提一下订单表为什么有唯一编号和状态字段。第五问“你遇到的最大困难是什么”——不需要说惊天动地的Bug就说联调时遇到跨域和日期格式问题然后你是怎么定位和解掉的这比“没有困难”更可信。6. 我建议按这个节奏推进排坑记录与时间表6.1 我踩过的代码级高频坑第一个是Maven依赖冲突。SSM项目里经常因为不同依赖传递引入了版本冲突的Jackson或Servlet API启动时直接报NoSuchMethodError。解决方式是先看报错堆栈定位到冲突的类再到pom里用exclusion把多余的传递依赖排除掉。不要上来就乱改版本号那只会引发新的问题。第二个是数据库连接时区错误。用MySQL 8.x时如果连接串里没有加serverTimezone启动时Tomcat会一直报Communications link failure。这个报错很有迷惑性表面看是连不上数据库实际只是时区配置缺失在JDBC连接串加一句就能解决。第三个是IDEA里修改代码后页面不生效。SSM项目必须确保编译输出目录里的class确实更新了。我在开发时遇到过改了Controller接口但前端访问还是旧逻辑的情况后来发现是IDEA热部署没生效手动重启或改用DevTools才解决。这类问题在联调阶段特别浪费时间遇到之后不要硬撑先把运行方式确定好再继续。第四个是路由的history模式刷新404。开发环境下刷新某个Vue路由页面会出现404因为后端没有把非API请求全部转发到index.html。最简单的处理是改回hash模式或者在后端做一个history fallback的转发规则。毕设演示时用hash模式就够了既省事又不容易在现场出丑。6.2 建议的七周推进时间表毕设最重要的是节奏我按每周一个里程碑给你排一个表周次任务产出第1周需求分析、功能清单、数据库表设计需求文档和建表SQL第2周搭建SSM工程完成用户注册登录和基础CRUD可运行的后端框架第3周实现景点、线路、酒店管理和搜索分页管理端核心接口第4周完成订单创建、支付模拟、评论收藏完整后端接口第5周搭建Vue工程完成门户页面和后台页面可演示的前端页面第6周前后端联调修复Bug补页面细节可提交运行的完整程序第7周写论文初稿、整理测试表格、做PPT论文初稿和答辩材料这个节奏比较宽松如果你前面被其他事情耽误了压缩到五周也来得及但数据库设计和前后端联调这两个阶段不建议压缩大多数返工都是因为这两个阶段没有做牢。6.3 让项目加分的扩展方向程序和论文都满足基本要求后如果还想在答辩时多拿一点印象分有几个低成本的扩展方向。热门景点加Redis缓存展示系统考虑到了热点数据的查询压力订单列表加一个Excel导出按钮把筛选结果导出成表格文件后台加两个统计图表展示每周订单数量的走势和热门线路排行最后把项目部署到云服务器上用公网地址现场演示比在本地IDEA里演示要显得完整得多。扩展的前提是稳住核心功能不要为了加一个华而不实的功能把原来的业务搞坏。我见过不少同学在最后阶段想加支付对接、地图定位结果没做成熟还引入一堆报错最后连基础功能都演示不了。毕设答辩看重的是完成度和理解深度你把你做的每一个模块都讲得明明白白比罗列一堆没跑通的功能强得多。最后说一句个人体会做这种全栈毕设项目最大的收获不是我“会用了某个框架”而是我搞清楚了一个请求从浏览器到数据库、再从数据库回到页面的完整旅程。把这条链路走通毕业设计这件事你就已经赢了九成。