开题季动不动就有人跑群里问毕设选什么题目好技术栈用什么难不难要不要选SpringBoot说实话这种问题没法一概而论但如果你问我有没有一个性价比比较高的方向我确实会推荐基于SpringBoot的线下演出售票管理系统这一类题目。这个题目不是那种炫技型项目也不是那种纯增删改查凑字数的水项目。它是一个业务场景清晰、技术栈主流、开发体量适中、答辩素材充足的典型Java Web毕设选题而且配套资源一般会比较完整——源码、SQL脚本、设计文档、调试指导、代码讲解几乎一应俱全拿来直接研究、二开、跑通、答辩都行得通。这篇文章我就把自己实际做项目、帮人看毕设过程中对这个题目的理解从选题逻辑、技术栈拆解、数据库设计、核心模块实现、环境调通到答辩演示完整捋一遍。不管你是刚接触Java的小白还是已经有SpringBoot基础想找一个稳妥的毕设方向这篇内容都值得你花十分钟读完然后照着去准备。1. 这个题目凭什么值得选从需求体量到答辩红利1.1 先看业务演出售票是一个真实且看得见的场景很多学生选题有个通病题目要么太虚构比如某某管理系统连使用对象都说不清楚要么太空中楼阁答辩时老师问一句你这个系统解决了什么实际问题直接卡壳。线下演出售票系统没有这个问题。你现在随便打开一个票务平台或者看看本地LiveHouse、剧院、音乐节的售票情况就能理解这个系统在干什么——演出方要发布演出信息场地方要管理场次和座位用户要在线浏览演出、选座、下单、取票主办方还要看销售数据。这个链条是真实存在的而且你身边随时能找到例子。选题有现实业务背书意味着你做需求分析时不是凭空编需求而是从现实场景里翻译需求。这一点在开题报告和答辩环节特别占便宜。老师问你为什么做这个系统你不需要背什么高大上的套话你就说演出市场活跃、线下票务管理效率低、需要一个统一平台管理演出信息、座位、订单和销售统计这就是一个说得通的理由。1.2 再看体量复杂度恰好卡在能做完和撑得起答辩中间毕设翻车最常见的原因不是题太难做不完就是题太简单没东西写。演出售票系统的复杂度刚好落在一个非常舒服的区间。它包含完整的CRUD演出信息、场次、用户、公告、评论这些是基础操作拿来练手、撑代码量。它有核心业务链路选座、下单、座位状态变更、订单状态流转这条链路涉及事务、唯一约束、状态判断是答辩时最有含金量的部分。它有统计报表需求按演出、按场次、按时间统计售票情况天然适合做图表展示让你在功能演示时多一个亮点。它可以扩展如果学有余力还能加抢票限流、座位图可视化、二维码取票、邮件通知每一个扩展点都是加分项。对比一下纯学生管理系统太单薄老师一眼看穿高并发秒杀系统又太复杂光一个分布式锁就能把你困在调试里两周。演出售票系统的定位是业务丰富但可控这是它适合做毕设的核心原因。1.3 附带资源的价值拿到源码之后怎么用才是关键现在很多毕设题目后面都跟着附源码、mysql、文档、调试代码讲解这类字眼这套资源的价值在于它帮你省掉了从零起步的探索成本但千万别把它当成交上去就完事的捷径。正常的资源使用路径是这样的先把环境搭好、把项目跑起来让系统在本地能启动、能登录、能下单然后对照文档把每个模块的代码看一遍理解核心流程最后选一个地方做改造——比如把原来自带的某个功能换成自己的思路或者增加一个模块。答辩时你能说清楚哪些地方是你自己写的、为什么这么写这就够了。比较危险的做法是拿到源码改个标题、换几个数据库表名就直接交。现在的导师和答辩评委都很清楚毕设市场的水深他们可能不会逐行查代码但一定会问实现细节。问几个关键类在哪个包、表结构为什么这么设计、某个流程的异常怎么处理你答不上来就非常被动。所以资源可以当拐杖但千万别当轮椅。2. 技术栈拆解SpringBoot、Java Web和MySQL在这场考试里的分工2.1 SpringBoot解决了什么从配置文件地狱里解放出来SpringBoot在毕设场景里受到欢迎核心原因就一条约定优于配置。以前的SSM整合项目要写Spring配置文件、SpringMVC配置文件、MyBatis配置文件还得处理各种jar包版本冲突光搭环境就得消耗两三天。SpringBoot用起步依赖简化了依赖管理用自动配置接管了绝大部分基础设置你只要引入spring-boot-starter-web一个内嵌的Tomcat就帮你把这层架子搭好了。对毕设来说这意味着你的精力可以集中在业务代码上而不是耗在环境搭建上。答辩的时候这也很好讲SpringBoot自动配置了DispatcServlet、数据源、事务管理器等组件开发时只需要通过配置文件或注解覆盖默认值。这个回答比我配了一堆XML听起来清晰得多。2.2 Java Web基础为什么不能丢SpringBoot只是封装底层机制还在不少同学学SpringBoot的时候跳过了Servlet、Filter、Session这些Java Web基础结果面试或答辩时一问就卡住。实际上SpringBoot并没有消灭Java Web它只是把Servlet容器内嵌了。演出售票系统里如果你做登录认证最基础的做法依然是利用HttpSession存用户状态用拦截器或Filter做访问控制。这个过程中你就会接触到HttpServletRequest/HttpServletResponse基础上的请求处理机制Cookie和Session的区别以及为什么登录态不会随便丢失拦截器Interceptor和过滤器Filter在SpringBoot里的注册方式哪怕你用JWT做无状态认证底层也绕不开在请求头里携带token、在拦截器里解析token这套逻辑。所以这个题目非常适合把Java Web基础知识和SpringBoot结合起来讲这也是答辩老师最喜欢问的层次——他要的不是你背出SpringBoot很强大这句话而是想确认你真的理解Web开发里请求-响应-状态管理这条主线。2.3 MySQL的角色数据持久化与业务约束的载体MySQL在整个系统里承担的不只是存数据很多时候业务规则本身就是靠数据库的设计来实现的。比如座位表里设置唯一索引保证同一个场次同一个座位不能重复插入这是防超卖的第一道防线。订单表和座位表的关联通过事务保证下单成功则座位被占、下单失败则座位释放的一致性。统计汇总时用SQL的聚合函数和分组查询直接计算出每个场次的售票数量、销售额比在Java里循环累加靠谱得多。我在帮人排查毕设问题的时候见过太多因为表设计不合理导致代码越写越难受的情况比如把座位信息拼成字符串存在订单表里导致统计查询无从下手比如没有考虑数据库的字符集问题导致中文乱码。后面的章节我会把表设计这些细节拆开讲。2.4 版本搭配一个稳定少坑的毕设环境组合版本问题看着不起眼但往往是卡住新手的第一个大坑。就这套技术栈我比较推荐的版本组合是下面这个稳定性经过很多项目验证。组件推荐版本说明JDK1.8 或 8SpringBoot 2.x系列最稳妥的搭配不要一上来就上JDK 17/21配合老项目Maven3.6.3 或 3.8.x3.6.3最稳3.8以下部分镜像仓库有问题需要注意配置SpringBoot2.3.x ~ 2.7.x2.7.x功能丰富且文档多别选3.x除非你非常清楚迁移风险MySQL5.7 或 8.05.7兼容性好8.0功能强但要注意驱动和SSL时区配置IDEA2022 或 2023对SpringBoot和Maven的支持最成熟这个组合的核心思路就一句话用经过大量验证的稳定版本而不是最新版本。热搜词里springboot版本太高这个坑绝对不要自己再去踩一遍。版本太高、依赖冲突、自动配置变化每一个都能消耗你一整天时间。3. 把需求翻译成表结构数据库设计是毕设成败的地基3.1 从业务场景提炼实体谁是主角、谁是配角设计数据库的第一步不是画ER图而是先搞清楚这个系统里有哪些角色、哪些对象、哪些行为。线下演出售票系统里核心角色有两类管理员和普通用户。核心对象有一个演出。围绕演出的有场次、座位、订单、票。附属对象还有公告、评论、轮播图之类。把这些实体列出来表结构的大框架就出来了用户表存账号、密码、昵称、手机号。管理员表与用户分开或通过角色字段区分取决于你如何设计权限。演出信息表存演出名称、类型、简介、宣传图、演职人员等。场次表存某个演出的某一场包含时间、场馆、票价档位。座位表按场次记录座位的区域、排、列、状态。订单表记录用户下单时间、订单号、总金额、状态。票表记录每张票对应的订单和座位。这个实体划分本身没有标准答案但它必须能让你的业务闭环讲通用户看到一个演出 → 选择场次 → 看到座位 → 选座下单 → 产生订单 → 订单里的座位被锁定 → 座位状态被更新 → 后台能看到销量统计。3.2 核心表设计要点拆表和不拆表之间的学问这里挑三个最容易出错的地方单独讲。第一演出信息和场次必须分开。一个演出可能在多个时间、多个场馆办多场如果把演出信息直接写在场次里演出信息的重复会导致数据冗余和修改困难。拆开之后演出表只管这是个什么演出场次表只管什么时候、在哪里、多少钱。这是答辩时典型的表设计加分点一定要能主动说出来。第二座位表不要和订单表混在一起。座位状态的变化要能够独立查询和管理。你的座位表应该有一个状态字段可以标记为空闲、锁定、已售。用户在选座时前端会拉取当前场次的所有座位状态已售和锁定的座位要么置灰要么禁止点击。下单成功后再把座位状态更新为已售。如果你把座位信息直接塞在订单里后面做这个场次还有哪些座位可售这种查询就会非常痛苦。第三订单和票要不要拆。我建议拆。订单是交易层面的事关注的是谁买了、买了多少、付了多少钱、状态如何票是履约层面的事一张票对应一个座位。拆开之后后续如果要加退票、换座、验票功能逻辑会更清晰。订单表订单号要唯一票表可以关联订单号和座位号。当然如果你觉得票表过于冗余也可以在订单明细表里体现但作为毕设多一张表意味着你多一个可讲的表设计理念。3.3 库存是怎么表达出来的座位状态与订单状态的联动售票系统的核心难点在于库存表达。场地里有多少座位就是多少库存。但要防止两个人同时买同一个座位光靠Java代码判断不够数据库层面得有约束兜底。在座位表设计里给场次和座位号加唯一索引是必要操作。例如在seat表里连续字段 (session_id, row_num, col_num) 应该被设为唯一这样即便代码层面出现并发插入数据库也会拒绝第二条记录。这个细节一旦你答辩时讲出来老师立刻会觉得你考虑过真实业务问题。订单状态一般设计为待支付、已支付、已取消、已完成。座位锁定可以有两种策略简单策略下单成功立即把座位标记为已售订单如果取消再把座位释放回空闲。稍复杂的策略下单后先锁定座位给用户15分钟支付时间超时未支付自动释放。对毕设来说简单策略够用但如果你想把业务做得完整第二种策略更能体现你对锁票和超时释放这类真实场景的理解。实现上也不难可以用定时任务扫描超过支付时限的待支付订单把对应座位状态改回去。3.4 数据库脚本里容易拖后腿的细节数据库脚本是拿回来之后第一件要执行的东西但细节陷阱特别多。我提几个高频问题。字符集数据库、表、字段都要统一用utf8mb4否则中文存储和查询会出现乱码。建库语句里应该带上charsetutf8mb4 collateutf8mb4_general_ci。存储引擎确保是InnoDBMyISAM不支持事务订单和座位联动就会出现严重一致性问题。外键不少毕设脚本会建外键但实际开发中很多人会去掉外键改用代码控制。如果你保留外键一定要知道外键约束对插入顺序有要求如果你去掉外键也要能解释清楚为什么不加外键——通常理由是性能和维护方便但需要在代码里保证引用完整性。索引除了主键给订单表的user_id、场次表的演出时间、座位表的场次与座位号组合都加上索引查询速度会有明显差异。把SQL脚本按照建库 → 建表 → 插入初始数据管理员账号、测试演出的顺序组织好这样别人拿到手才能顺利跑起来。很多资料包里的脚本写得很随意执行一遍报一堆错这本身就是给你的一个改造点——把脚本整理干净也是一个工作量答辩时能提。4. 核心功能模块的实现顺序与逻辑先搭骨架再补血肉4.1 登录认证与权限控制基本功也能讲出深度这个模块看似基础但设计得好不好直接影响后续所有功能。建议的做法是管理员和用户共用一个登录入口登录时根据账号角色决定跳转到管理端还是用户端。在SpringBoot里简单可靠的方案是用拦截器Session。登录成功后把用户对象放进Session自定义一个拦截器拦截需要权限的路径比如/admin/**需要管理员权限/user/**需要登录状态。没有登录就重定向到登录页。这个实现思路简单、稳定、好讲而且完全基于Java Web基础老师问你Session是什么、拦截器和过滤器区别是什么你都能接得住。如果你稍微想进阶一点可以用JWT实现无状态登录。用户登录后服务端签发token前端后续请求都带token拦截器里解析和校验。这种做法的好处是前后端分离时更好用但复杂度会高一些。建议基础薄弱的同学先用Session方案学有余力再改成JWT改的时候正好能加深理解。4.2 演出与场次管理把CRUD写出条理演出管理本质是CRUD但要注意CRUD之间是有依存关系的。合理的开发顺序是先做演出信息管理添加演出、编辑演出、上架/下架。再做场次管理在一个演出下添加多个场次包括时间、地点、票价、座位图设置。最后做前端展示按演出列表、演出详情、场次选择三层组织页面。很多同学上来就写前端页面结果后端接口连数据模型都没定。正确的姿势是先定数据模型再把Controller、Service、Mapper这层结构打通最后页面只是数据的呈现层。接口设计建议遵循REST风格比如POST /api/performance添加演出、GET /api/performance/{id}查询演出详情、PUT /api/session/{id}修改场次信息。这种接口风格规范、容易扩展而且现成的接口测试工具Postman、Apifox都能直接调试。4.3 选座下单整条业务链路的串联核心这是整个系统最有含金量的部分也是答辩时的重点建议把这段逻辑背熟。完整流程是这样用户在演出详情页选择场次后前端请求该场次的座位列表后端查询seat表按区域、排、列返回所有座位及其状态。用户点击可选座位确认购买后提交订单。后端要做的事情有校验座位是否存在、是否可售。校验用户是否登录。生成唯一订单号创建订单记录初始状态为待支付。更新座位状态为已售或已锁定。把订单和座位的关联关系写入票表。第1、3、4步必须在同一个事务里完成。实现方式就是在Service方法上标注Transactional一旦中间任何一步失败整个操作回滚不会出现订单创建成功但座位没占住或者座位占了却查不到订单的数据不一致问题。这里有一个比较容易忽略的地方订单金额要从数据库里的票价计算不能完全信任前端传过来的金额。比如前端恶意把票价改成1元提交如果你直接信任前端参数订单金额就变成1元了。正确做法是根据场次ID去数据库查票价再乘以购买数量由后端计算总金额。这个点也是答辩时老师爱问的安全问题之一。4.4 统计报表与数据可视化拉开差距的加分项很多基础版售票系统不带统计功能但毕设想拿高分强烈建议加上。因为统计功能能展示你对SQL聚合查询的掌握也能让系统看起来更完整。可以做的统计维度有各演出总售票数、总销售额排行。指定时间段内的订单量趋势、销售额趋势。每场演出的上座率已售座位数除以座位总数。按演出类型分类的销售占比。后端用SQL写统计查询返回给前端前端用图表库展示。不引额外前端框架的话ECharts是最成熟的方案直接通过CDN引入就能用柱状图、折线图、饼图都很好配置。统计页面的功能逻辑不太复杂但视觉效果好演示时非常加分。提一句清华开源项目里的ECharts也好百度的也好都是通用前端图表库毕设里放心用答辩时就说是使用ECharts开源图表库做数据可视化。4.5 再加几个小功能让系统内容更丰满基础功能完成后可以根据精力挑一两个加分功能搜索功能按演出名称模糊查询用MySQL的LIKE即可如果要更专业可以聊索引优化。公告管理管理员发布公告用户端公告栏展示。订单取消与退款用户未支付订单可取消已支付订单的可退场景可以做成简化版。图片上传演出宣传图上传到服务器本地或配置虚拟路径映射这里涉及文件IO和静态资源映射也是常见知识点。这些功能不需要全做挑一个做深了就是你答辩时区别于其他人的点。我自己见过一个学生只在系统里加了二维码取票功能——用户购票后生成一个二维码现场凭二维码核销。就这么一个功能他把QRCode生成、核销状态流转讲得明明白白评委当场给了一个很高的评价。功能不在多在于你能否把某一个功能讲透。5. 环境配置与部署调通的实操细节我见过的翻车重灾区5.1 本地开发环境的基础搭配先把地基夯结实这个系统的开发环境按照前面版本表格里那一套排下来就够了。但有几个容易被忽略的点JAVA_HOME环境变量一定要配好而且指向的路径不能带空格最好也别装多个JDK版本免得Maven和IDEA检测到混用情况。Maven的settings.xml里镜像建议用阿里云镜像或腾讯云镜像不然下载SpringBoot依赖时会慢到怀疑人生。IDEA里导入项目时选Maven的自动导入设置里检查一下构建工具的项目编码是否为UTF-8。不建议用Spring Boot 3.x配JDK 8Spring Boot 3最低要求JDK 17很多老教程和依赖配置都不适配完全没必要给自己上难度。5.2 导入项目和初始化数据库时的几个坑拿到一个已完成的毕设项目后导入流程一般是IDEA打开项目根目录 → 等Maven下载依赖 → 修改application配置文件的数据库连接 → 执行SQL脚本 → 启动项目。这里容易翻车的位置集中在配置文件。你的application.yml或application.properties里通常要配置这几项spring: datasource: url: jdbc:mysql://localhost:3306/ticket_system?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver server: port: 8080注意几个细节MySQL 8.0的驱动类是com.mysql.cj.jdbc.DriverMySQL 5.7旧驱动也可以兼容但建议直接用8.x连接串上serverTimezoneAsia/Shanghai是为了避免时区报错useSSLfalse是为了避免SSL握手问题这两个参数加不加直接影响能不能启动成功。数据库初始化时先确认要把SQL文件导入的目标数据库名称和配置里的库名一致否则会出现Table不存在或数据库不存在的报错。执行SQL时如果提示某字段重复或者字符集问题仔细读报错信息一般是脚本里混入了旧版本的数据定义删掉重来即可。5.3 MySQL连接报错把排查思路讲清楚比直接给答案更重要用Java连接MySQL时报错类型就那么几种但每个报错背后对应的原因完全不同。我建议你按下面的顺序排查。第一种启动时提示Access denied for user rootlocalhost这就是用户名或密码不对检查配置文件的密码以及你本地MySQL root账号的认证方式。MySQL 8.0默认用caching_sha2_password老驱动可能不支持你可以在MySQL里改成mysql_native_password或者把MySQL驱动版本升到8.0以上。第二种提示Communications link failure一般是连接串端口写错、MySQL服务没启动、防火墙拦截。先用命令行mysql -uroot -p确认MySQL能正常连接然后用telnet localhost 3306或netstat -an看端口是否开放。这个排查链路很常规但能帮你快速定位是服务问题还是配置问题。第三种提示The server time zone value XXX is unrecognized这就是连接串缺serverTimezone。说到底就是MySQL服务器时区和客户端期望的时区不一致加上参数即可。第二种常见的SSL connection error也是同类问题连接串加useSSLfalse跳过SSL校验即可。这些都是毕设起步时的经典坑踩过一次记得写进你自己的笔记里答辩或者帮同学排查时就是经验。5.4 SpringBoot版本太高引发的问题为什么我劝你别折腾热搜词里springboot版本太高说明这不是个别现象。Spring Boot 3.0之后默认的Java版本是17某些依赖的兼容性要求也变了——比如javax命名空间改成了jakarta、某些自动配置类被重新组织。你搜到的大部分教程和现成代码是基于Spring Boot 2.x的直接套用会出现各种不兼容报错。所以如果你拿到手中的代码是基于SpringBoot 2.x写的就老老实实用2.x把系统跑通别为了赶新潮强行升3.x。除非你的导师明确要求用新版本并且你有充分时间处理兼容问题否则风险远大于收益。毕设的核心是系统功能和你的理解深度而不是框架版本号。5.5 本地运行通过之后打包部署环节的顺带处理系统调通之后建议把打包这一步也走一遍因为答辩现场不一定有条件开IDEA运行如果能打成可执行jar包或者war包部署到服务器上演示会更稳。SpringBoot打包很简单在项目根目录执行mvn clean package然后去target目录找生成的jar包在命令行运行java -jar target/ticket-system-0.0.1-SNAPSHOT.jar注意打包后访问端口是配置文件里配置的端口前端页面如果是打包在SpringBoot的static目录下直接浏览器访问http://localhost:8080即可。如果前端是独立Vue项目则需要先npm run build再把dist目录里的文件放到SpringBoot的static目录或者用Nginx配置反向代理。对纯后端的小伙伴来说前一种方案更稳妥。部署到服务器的话需要服务器上有JDK环境配置文件里数据库地址要改成服务器的数据库地址必要时可以用外部配置文件覆盖jar包内的配置这个就属于进阶了毕设不太强求但会了肯定是加分项。6. 答辩演示怎么把六十分的项目讲成九十分6.1 演示路线设计从有什么到怎么做再到为什么答辩时最忌讳两种演示方式一种是一上来就打开前端页面点点点老师看得云里雾里另一种是从代码的第一个类开始逐行讲时间根本不够。正确的路线应该是业务 → 架构 → 功能 → 亮点四段式。第一段用两分钟讲清楚你要做什么线下演出售票的背景系统有哪些角色解决什么问题。第二段用架构图或模块图说明技术分层SpringBootMyBatis/Spring Data JPAMySQL前端用什么后端分Controller、Service、Mapper几层登录怎么做鉴权数据库一共几张核心表。第三段是功能演示按下面这条路径走管理员登录 → 添加演出和场次 → 用户登录 → 浏览演出 → 选座下单 → 订单列表 → 统计报表。这条路径把系统的核心功能全部覆盖一气呵成。第四段是主动讲亮点选一两处你实现得最用心的设计比如用事务保证订单和座位一致性、座位唯一索引防超卖、数据统计用聚合查询实现。6.2 高频问题与应对思路答辩评委的问题其实有一定的套路下面这几个问题基本属于必问范畴提前准备好就不会慌。问为什么用SpringBoot而不用SSM答SpringBoot简化了配置和依赖管理内嵌Tomcat使项目可独立运行自动配置减少了大量样板代码但底层依然是Spring MVC Servlet核心机制相同。这个答案把新旧框架的关系说清楚了。问数据库表是怎么设计的为什么演出和场次分开答一个演出可以有多场拆成两张表避免重复存储方便按场次管理座位和订单符合第三范式的思想。问怎么防止同一个座位被两个人买到答两个层面代码层面在事务里先查询座位状态再更新数据库层面座位表对场次和座位号加唯一索引即使并发也只会有一条插入成功。问下单过程中如果第4步失败了怎么办答方法使用 Transactional 声明事务任何异常都会触发回滚订单、座位状态、票记录会一起回滚到操作前的状态保证数据一致性。问你的系统有没有考虑性能问题答毕设体量下主要做了合理索引如果进一步优化可以给热门场次加Redis缓存减少数据库压力。这个回答既诚实又有扩展空间。6.3 演示中千万别做的三件事第一别在答辩现场当场改代码。哪怕报错改起来只需要一秒导师的印象也会直线下降。所有演示脚本必须提前完整走一遍包括测试账号、测试演出数据、测试订单流程都要提前准备好。第二别只讲CRUD不讲业务。如果整场答辩都在说这个模块可以增删改查老师会觉得你做的和课设作业没区别。一定要主动把业务链路串起来讲比如用户选座 → 下单 → 事务更新座位 → 订单与票关联这条链路才是这个项目的真正价值。第三别吞吞吐吐说不清自己做的部分。如果资源是你参考的就光明正大说自己理解了哪些、改了哪些、加了哪些。老师们其实并不排斥参考优秀源码他们排斥的是不懂装懂。把源码吃透再在上面加工出自己的痕迹就是一条稳妥的路。这些年帮人看毕设代码我最深的体会是毕业设计的价值不在于代码的华丽程度而在于你有没有真正理解自己交付的系统。演出售票管理系统这个题目胜在它足够真实、足够完整、也足够让你在准备过程中把SpringBoot、MySQL、Java Web这些核心技术点全部过一遍。拿到任何一份配套资料都不要急着跑通就完事先画一张模块图理清结构再跟着数据流把核心代码逐行走一遍最后选一两个坑亲手排查一遍。这套流程走下来你手里的项目才是真正属于你的答辩时那种底气自然就有了。