计算机毕业设计选了拍卖管理系统这个题目的同学，大多是被"管理系统"三个字吸引过来的，以为就是普通的增删改查。但真正动手做才发现，拍卖系统是个"带刺的玫瑰"——表面上是个常规管理平台，内核里却藏着并发出价、状态流转、自动延时、订单闭环这些硬骨头。我用Spring Boot从零把这个系统完整做下来，前前后后踩了不知道多少坑，这篇就把整个项目的设计思路、核心代码、并发处理方案和避坑记录全部复盘一遍。不管你是正准备开题的准大四，还是想拿Spring Boot练手做完整项目的开发者，这篇都可以直接当成你的项目参考手册。
1. 项目需求分析与整体设计思路
1.1 毕业设计选型：为什么是Spring Boot做拍卖系统
毕业设计选系统开发题，最怕的是选题太"水"。普通的管理系统，比如图书管理、学生管理、仓库管理，做来做去就是几张表的CRUD，答辩老师一眼就能看出工作量和深度都不够。我选拍卖管理系统，核心原因就一个：这个业务场景天然带着复杂度。
拍卖系统的业务链条非常完整——用户管理、拍品管理、竞价、保证金、订单、支付、后台审核，每个环节都有自己的规则。而且竞价这个核心动作，天然就是高并发的战场：同一个拍品可能同时有几十上百人出价，怎么保证数据不错乱？这件商品即将结束时有人出价，要不要延时？这些问题在普通管理系统里根本不存在，但在拍卖系统里必须正面解决。
技术栈选Spring Boot，说实话没什么可纠结的。当前Java后端开发的主流框架就是它，毕业设计跟着主流走永远没错。Spring Boot的好处用一个词概括就是"少配置"——内置Tomcat，依赖管理省心，一个@SpringBootApplication注解就能把项目跑起来。像早些年SSH那种动辄几十行XML配置的苦日子，做毕业设计真的没必要体验一遍。配上MyBatis Plus做数据库操作，Maven一键拉依赖，开发效率拉满，能让你把时间花在真正的业务逻辑上，而不是环境配置上。
1.2 拍卖系统的核心业务场景拆解
拿到题目先别急着写代码，磨刀不误砍柴工。我花了整整两天时间，把拍卖系统的业务场景拆成了四个主闭环：
- 管理端发布拍品：运营人员登录后台，填写拍品标题、起拍价、加价幅度、起拍时间、结束时间，上传图片，提交审核。
- 用户端参与竞拍：用户浏览拍品列表和详情，在竞拍时间内出价，出价必须高于当前最高价且达到最低加价幅度。拍卖结束后，最高出价者胜出。
- 成交与订单：竞拍结束后自动生成订单，胜出者进入支付流程，完成支付后订单闭环。
- 后台运营：管理员审核拍品、管理用户、查看统计数据、处理异常订单。
这四个闭环看着清晰，但每个环节往里深挖都是细节。比如用户出价被超越时要不要通知？拍卖结束后保证金怎么退还？用户支付超时订单要不要取消？我在画业务流程图的时候，专门把每个状态节点的触发条件标注出来，后面写代码时对照流程图走，逻辑就不会乱。
1.3 功能模块规划与数据库设计思路
模块划分最终定成七个：用户模块、拍品模块、竞价模块、订单模块、支付模块、后台管理模块、通知模块。
数据库设计是整个项目的地基，我在这上面栽过跟头，直接把经验写出来。第一，状态字段全部用数字存，不要用字符串。比如拍品状态我定义成四个：0待审核、1竞拍中、2已结束、3已成交，用tinyint存储，代码里配合枚举类使用，副作用是状态流转的逻辑必须集中管理，但这反而是好事。第二，价格金额一律用decimal(10,2)，谁用float谁后悔，浮点运算丢精度的问题在你做金额汇总的时候会把你搞崩溃。第三，多建索引。竞价记录表查询频率极高，item_id和bid_time必须建联合索引，否则数据量一上来，接口响应时间会肉眼可见地变慢。
核心表我建了六张：用户表、拍品表、竞价记录表、订单表、保证金流水表、通知表。用户和拍品是一对多，拍品和竞价记录是一对多，订单关联拍品和用户。表结构设计阶段多想十分钟，后面写代码能少花三天。
2. 系统架构与核心技术选型
2.1 技术栈为什么这样搭
最终技术栈定的是：Spring Boot 2.7.x做基础框架，MyBatis Plus做ORM，MySQL 8.0存数据，Redis做缓存和分布式锁，JWT做登录认证，前端用Vue3加Element Plus。
有人纠结MyBatis Plus和JPA怎么选，我的建议很实际：毕业设计用MyBatis Plus。原因之一是它的代码生成器极其实用，能从数据库表一键生成实体类、Mapper接口、Service和Controller的样板代码，省下来的时间全砸在真正有含金量的业务逻辑上。另一个原因是面试和答辩时，MyBatis Plus的QueryWrapper和分页插件都是高频提及点，讲出来有话说。JPA虽然也很火，但抽象程度高，调试起来比SQL直观程度差不少，毕业设计阶段追求的是稳妥和可控。
2.2 认证与权限控制方案
登录认证方案这块，我直接说结论：用JWT加一个拦截器就够了，没必要硬上Spring Security全家桶。Spring Security本身是个很强大的框架，但配置复杂度高，学习曲线陡，在毕业设计时间节点上，把精力耗在那里非常不划算。
JWT方案总共就三步：用户登录成功后，后端生成一个包含userId和role的token返回给前端；前端每次请求都把token放在HTTP请求头里；后端拦截器统一解析请求头的token，解析成功放行，并把用户信息放进请求上下文。整个链路没有session、没有状态，实现干净利索。
唯一要注意的细节是JWT的加密密钥：绝对不能写死在代码里，要放在application.yml配置文件中，密钥长度建议用48位以上的随机串。太短的密钥可以被暴力破解，一旦密钥泄露，等于整个登录体系形同虚设。
2.3 前后端分离的部署架构
系统采用前后端分离架构，这也是当前Web开发的事实标准。前端项目单独维护，通过接口与后端通信，接口风格走RESTful。开发环境下，前端用Vite起本地服务，通过代理转发请求到后端，规避跨域问题；生产环境则把前端打包后的静态文件交给Nginx托管，Nginx再把API请求反代到Spring Boot服务。
这套架构的好处很明显：前后端职责边界清晰，前端专注页面渲染和交互，后端专注业务逻辑和数据持久化。答辩时老师问起系统如何部署，你可以从容回答"Nginx托管前端静态资源、反向代理到后端服务、后端连接MySQL和Redis"，一套标准的生产级链路讲下来，专业性直接拉满。
2.4 项目目录分层与代码组织
项目代码组织上，我强烈建议用标准Maven结构配合清晰的分层package。我最终的项目目录长这样：
com.example.auction ├── controller 接口控制器，只做参数接收和结果返回 ├── service 业务逻辑层，核心业务全部在这里 ├── mapper MyBatis Plus数据访问层接口 ├── entity 数据库实体类 ├── dto 数据传输对象，用于接口入参 ├── vo 视图对象，用于接口返回数据 ├── config 配置类，拦截器、跨域、异常处理 ├── utils 工具类，JWT、时间处理等 └── common 公共类，统一返回结果、枚举、常量、异常这样分层带来的直接好处是，答辩时被问到任何一类问题都能精准锁定位置：异常处理统一在config和common里，业务逻辑在service里，数据访问在mapper里。口齿清楚地讲出这套分层逻辑，老师想刁难你都不好意思。
3. 核心功能模块详解与实现要点
3.1 用户注册登录与权限控制
用户注册接口的核心逻辑是校验用户名唯一性、密码加密存储、初始化角色为普通用户。密码加密这里我必须多说两句：直接用MD5存密码是极大的安全隐患，彩虹表一查就能还原出明文。正规做法是每个用户生成一个随机盐值，把盐和密码拼接后再做散列计算。更安全的是用BCrypt做加盐哈希，但有些同学为了在答辩中把加密流程讲得更直观，用MD5加盐也能自圆其说，关键是脑子里要绷紧"密码绝不能明文存储、绝不做裸MD5"这跟弦。
登录成功后生成的JWT，我在Claims里封装了userId和role两项。后面所有需要用户身份的接口，直接从token里解析当前用户，省掉了每次查库的开销。拦截器实现其实只有十几行代码，继承HandlerInterceptorAdapter，重写preHandle，从请求头拿到Authorization字段，去掉Bearer前缀，丢给JWT工具类解析，解析失败直接抛401。注册拦截器时要注意放行登录、注册、拍品列表、拍品详情这些匿名可访问的接口，其余的统统拦下校验。
3.2 拍品发布与状态流转设计
拍品状态管理是整个系统的骨架。我在项目里定义了一个枚举类来统一管理状态：
public enum AuctionStatus { PENDING(0, "待审核"), AUDITING(1, "竞拍中"), FINISHED(2, "已结束"), DEAL(3, "已成交"), CANCELED(4, "已取消"); }这里最关键的设计是不允许业务代码各自随意修改拍品状态，我封装了一个统一的状态更新方法，所有状态变更都走这一个入口，并且顺带记录变更时间。这样做的好处，等系统运行一段时间出了线上问题时就会深有体会——你翻日志能清晰还原每一件拍品从发布到成交的全过程，而不需要两眼一抹黑地猜。
拍品审核通过的瞬间，系统要做两件事：一是把状态从待审核改成竞拍中，二是把开始时间设置为当前时间（或预设时间），结束时间保持管理员设置的值。这部分逻辑一定要保证在同一事务里执行，防止出现拍品状态已经改了但时间没设置好的中间状态。
3.3 竞价核心流程：出价、保证金与自动延时
竞价是系统的灵魂模块。单个用户的一次完整出价，业务逻辑分这么几步：
- 校验拍品处于"竞拍中"状态；
- 校验当前时间在endTime之前；
- 校验出价金额大于当前最高价且达到加价幅度；
- 冻结用户相应比例的保证金；
- 写入竞价记录，更新拍品的当前最高价和最高出价人。
这里有一个细节很容易忽略：很多同学图省事，等到拍卖结束后去竞价记录表里取金额最大的那条当作成交依据。但实际运营中，系统可能做过数据修正，竞价记录表和拍品的当前价字段不一定完全一致。因此成交价必须以拍品表里的current_price字段为准，竞价记录只作为历史追溯依据。能主动想到这一点，答辩演示时就是加分项。
自动延时是拍卖系统典型的业务规则：如果结束前最后30秒内有新出价，拍卖结束时间自动顺延30秒。起初的实现很简单，出价成功后判断剩余时间小于30秒就把endTime更新成当前时间加30秒。但要注意，更新endTime的SQL必须和出价写入放在同一个事务里，否则可能出现用户出价成功但结束时间没更新，稍后系统错误地把拍卖关闭了。这个问题我可是踩过的，事务边界没划清楚，数据状态就会变得极其妖异。
保证金这块，我做得相对简化但逻辑完整：用户先往账户里充一笔虚拟余额，出价时系统按规则冻结资金。被超越的出价人解冻资金，最终胜出者订单金额从冻结资金里抵扣，不足部分提示补缴。整个流程靠一张保证金流水表把每一笔资金的来龙去脉都记录下来，查账的时候一目了然。
3.4 订单生成与模拟支付
拍卖结束后怎么生成订单，我先后试过两种方案。第一种是用户进入"我的得标"页面，手动确认后生成订单，逻辑简单但体验割裂。第二种是定时任务扫描已结束的拍品，系统自动为最高出价人生成订单，我最终采用第二种，原因是"限时拍卖"天然是个确定性场景，由系统触发生成最可靠。
订单编号这块必须自己生成，不能依赖数据库自增ID。我采用的规则是"时间戳加用户ID加随机数"，这样既能保证唯一性又能防止并发下重复。订单表冗余存储拍品标题、成交价、卖家ID这几个字段，从三范式角度看是冗余了，但实际查询时能少关联两张表，性能和开发效率都明显提升。毕业设计阶段这种"用空间换时间"的取舍是完全合理的。
支付功能做成模拟支付：用户点击支付按钮，系统把订单状态从待支付改成已支付，并写入支付流水表。答辩时重点不在于真的接通支付宝微信，而在于把"支付动作完成后的状态流转和用户通知"这条链路讲清楚，这比支付本身更接近系统的真实设计逻辑。
3.5 后台管理模块
后台模块本质上是一组带过滤条件的列表操作。管理员可以查看全部拍品列表，按状态筛选，通过审核或强制下架；查看注册用户列表，封禁违规账号；查看成交记录和每日数据统计。
列表分页直接用MyBatis Plus的Page对象，简单可靠。模糊查询用QueryWrapper.like方法，MyBatis Plus底层是预编译参数，天然防SQL注入，但如果自己手拼SQL就要格外小心了。后台统计这块，我写了定时任务每天凌晨跑一次，计算当天的成交总额、新增用户数、出价次数，存进一张统计汇总表。虽然实时统计也能做，但做快照的好处是趋势图数据稳定、报表好画、答辩演示也不卡顿，视觉效果好得多。
3.6 站内信通知模块
通知这块是容易被忽略但其实很出彩的模块。用户出价被超越、竞拍成功、支付完成、拍品审核结果，这些事件都要及时触达用户。我没有上MQ消息队列，因为对这种内部异步需求，同步调一个NotificationService.send()方法反而是最清晰、最不容易出错的实现方式。
4. 并发竞拍的数据一致性实战
4.1 并发出价问题的出现
第一版出价逻辑是最朴素的"先查询再判断最后更新"：查出当前最高价，判断用户出价是否合法，合法就写入记录。单用户测试一点问题没有，但我用JMeter模拟100个并发用户同时出价后，问题当场暴露。最终成交价和竞价记录完全对不上，甚至出现了两条金额相同的最高出价记录。
原因很简单：两个并发请求同时读到了同一个"当前最高价"，都认为自己出价有效，先后执行了写入操作，后写入的覆盖了先写入的。这种问题在普通CRUD系统里永远不会出现，但在拍卖系统里是必须跨过的坎。说实话，这个难题恰恰是拍卖系统这个选题最值钱的地方——它逼着你真正思考并发场景下的数据一致性。
4.2 第一层防御：数据库行锁
最直接的办法是引入悲观锁：出价前执行SELECT ... FOR UPDATE把当前拍品记录行锁住。在MySQL的InnoDB引擎下，这条语句会锁住对应行，直到事务提交或回滚。这样并发出价请求就变成了串行执行——先来的请求先更新最高价，后来的请求读到新值，自然因为加价幅度不足而失败。
悲观锁的好处是数据绝对正确，代价是吞吐量受限，同一件拍品在高并发时请求会排队。但作为毕业设计，能讲清楚"行锁保证一致性，并发瓶颈仅存在单件拍品维度"这个权衡，已经是相当优秀的分析了，而且数据库行锁是面试里最高频的考点之一。
4.3 第二层优化：乐观锁与版本号
在拍品表增加一个version字段，每次更新最高价时带上条件where id = ? and version = ?，更新成功version加1。执行更新语句后返回影响行数，如果为0，说明版本号已经被其他请求改了，当前请求就判定失败。这个方案实现简单、代码优雅，但高并发下失败率偏高。我最终的做法是：常规出价用乐观锁处理，而"自动延时"这种改时间字段的操作放在事务内单独处理，不让两类操作互相拖累。
这里有个有意思的点：乐观锁更新失败后不能直接把错误抛给用户说"出价失败"，更友好的做法是提示"当前价格已变化，请刷新后重试"，让用户重新看最新价格再出价。这种细节打磨会让答辩老师觉得你真的理解业务，而不只是写完代码交差。
4.4 Redis缓存、限流与兜底
在并发优化上还可以再加一层Redis兜底。我做了两件事：第一，把处于竞拍中的拍品详情缓存到Redis里，高频的只读请求打缓存不打数据库，大幅减轻数据库压力；第二，用Redis的INCR命令给每个用户的出价动作做限流，key格式是auction:user:{userId}:item:{itemId}，同一用户对同一拍品的出价频率限制在每秒一次。
这套组合拳打下来，我用JMeter再压100并发，数据完全正确，接口请求也没有出现雪崩级别的抖动。并发压测这个环节可以完整写进毕设论文的"系统测试"章节，图表一放、数据一讲，项目深度直接提升一个档次。
4.5 定时任务关闭过期拍卖
拍卖截止依赖定时任务扫描。我用Spring自带的@Scheduled注解，每30秒扫描一次所有竞拍中的拍品，把endTime小于当前时间的一批拍品状态改成已结束，触发订单生成和通知。@Scheduled用起来极简单，但要知道单机部署下默认是单线程执行任务，如果以后要集群部署，就得上分布式锁或者xxl-job这类框架。毕业设计阶段单机没任何问题，但心里要留根弦。
定时任务里还有个不显眼但致命的点：时间判断一定要统一基于服务器时间。前端传入的时间戳和后端当前时间可能有偏差，如果不做时区规范，就可能出现"服务器已经结束但用户还在出价"的诡异状态。
5. 从零搭建项目的实操步骤
5.1 环境准备与项目初始化
开发环境我列个清单：JDK 1.8或11、IntelliJ IDEA（社区版完全够用）、MySQL 8.0、Redis 6.x、Navicat或DBeaver、Postman用于接口测试。
好多人问我IDEA社区版能不能开发Spring Boot项目，我的体验是完全可以。社区版没有Spring Initializr插件，但可以直接打开Spring官网的start.spring.io页面，填好项目信息、勾选依赖，下载压缩包，再用IDEA导入，效果一模一样。Lombok插件在插件市场单独装一下就行。所以别再纠结是不是要装破解版旗舰版了，工具不背锅，代码写得好才是硬道理。
项目初始化时，我建议直接在pom.xml里整理依赖，比网页点选更可控。核心依赖包括spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、spring-boot-starter-data-redis、jjwt-api、lombok。
5.2 数据库建库与核心表结构
拍品表的核心结构直接给出来，照着建表就能跑：
CREATE TABLE auction_item ( id BIGINT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(200) NOT NULL COMMENT '拍品标题', description TEXT COMMENT '拍品描述', images VARCHAR(2000) COMMENT '图片地址，逗号分隔', start_price DECIMAL(10,2) NOT NULL COMMENT '起拍价', step_price DECIMAL(10,2) NOT NULL COMMENT '加价幅度', current_price DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT '当前最高价', start_time DATETIME NOT NULL COMMENT '开始时间', end_time DATETIME NOT NULL COMMENT '结束时间', seller_id BIGINT NOT NULL COMMENT '发布人ID', version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', status TINYINT NOT NULL DEFAULT 0 COMMENT '状态', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_seller (seller_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='拍品表';要重点强调的两点：字符集必须用utf8mb4，否则存不了生僻字和Emoji图标直接报错；竞价记录表要给item_id和bid_time建联合索引，查询性能天差地别。
5.3 核心代码实现
出价接口的Spring服务层代码是整套系统的核心，核心逻辑就是这样：
public boolean bid(Long userId, Long itemId, BigDecimal price) { AuctionItem item = auctionItemMapper.selectById(itemId); if (item.getStatus() != AuctionStatus.AUDITING.getCode()) { throw new BizException("该拍品不在竞拍中"); } if (LocalDateTime.now().isAfter(item.getEndTime())) { throw new BizException("拍卖已结束"); } if (price.compareTo(item.getCurrentPrice()) < 0) { throw new BizException("出价不能低于当前价"); } if (price.subtract(item.getCurrentPrice()).compareTo(item.getStepPrice()) < 0) { throw new BizException("加价幅度不足"); } int rows = auctionItemMapper.bidWithVersion(item.getId(), price, item.getCurrentPrice(), item.getVersion()); if (rows == 0) { throw new BizException("出价失败，请刷新后重试"); } auctionRecordMapper.insert(new BidRecord(userId, itemId, price)); if (item.getEndTime().isBefore(LocalDateTime.now().plusSeconds(30))) { auctionItemMapper.extendEndTime(item.getId(), LocalDateTime.now().plusSeconds(30)); } return true; }对应的乐观锁更新SQL要放在Mapper接口的XML里：
<update id="bidWithVersion"> UPDATE auction_item SET current_price = #{price}, version = version + 1 WHERE id = #{itemId} AND version = #{oldVersion} AND status = 1 </update>注意这个SQL带了status = 1条件，相当于在更新的同时再校验一次拍卖状态，双保险。这套代码是整个项目的技术精华，能独立讲清楚，答辩就已经成功了一大半。
5.4 全链路测试流程
项目写完之后，千万不要只跑通一个下单接口就宣布完工。我自己整理了一套全链路冒烟测试流程，每次改完代码都完整跑一遍：
- 注册两个普通用户账号A和B；
- 用管理员账号登录，发布一件起拍价100元、加价幅度10元的拍品；
- 在"待审核"状态下，验证用户A出价会被拒绝；
- 管理员审核通过，确认拍品进入竞拍中状态；
- 用户A出价100，用户B出价120，B领先；
- A出价130，B在最后20秒时出价140，确认结束时间自动延长30秒；
- 停止出价等待结束，确认系统自动生成订单，订单金额为140元；
- 用户A登录并支付，订单状态变为已支付；
- 管理员后台看到成交记录和统计数据。
这套流程跑完，系统的核心链路就全部验证过了。每次改动代码后跑一遍，比写什么测试文档都有用。
6. 常见问题与排查技巧实录
6.1 并发数据错乱问题
现象：并发压测时，成交价和竞价记录对不上，甚至出现两条并列最高价。
排查过程：先关闭并发做单用户测试，能复现说明是逻辑Bug，不能复现再上JMeter并发压测。最终定位到旧版本代码里update语句漏了version条件，两个请求同时通过金额判断后先后执行更新，后执行的覆盖了先执行的currentPrice。
解决思路就是前面讲的乐观锁方案。整个排查过程总结一句话：先判断、再更新、更新失败就明确告诉用户失败，绝不静默丢数据。这个排查思路是通用方法，任何并发问题的排查都能复用。
6.2 时区导致的拍卖时间错乱
现象：后台设置的结束时间是23:00，用户端却显示07:00，拍卖结束判定跟着一起错乱。
排查：数据库里存的时间本身没问题，问题出在Json序列化时区偏移。Spring Boot的Jackson默认使用服务器时区，如果服务器是UTC而浏览器是东八区，就会出现8小时偏差。
解决：在application.yml里强制指定：
spring: jackson: time-zone: Asia/Shanghai datasource: url: jdbc:mysql://localhost:3306/auction?serverTimezone=Asia/Shanghai数据库连接串也要加serverTimezone=Asia/Shanghai，两步配置做完，时间错乱问题就能彻底根治。
6.3 内存问题
现象：压测跑了半小时，堆内存持续增长最后OOM。
排查：从堆栈发现竞价记录查询没有分页，每次把整表记录list()出来在内存里排序拼接。这种问题在数据量小的时候毫无感知，一旦数据量上来立刻爆发。
解决：所有列表查询强制分页。MyBatis Plus的Page对象顺手就用，再配上慢SQL日志，超过阈值的查询一眼就能看到。
6.4 部署上线踩过的坑
云服务器部署主要就这几件事：装JDK、MySQL、Redis、Nginx，把后端打包成jar包、前端dist目录丢上去。几点提醒：
- MySQL和Redis的端口不要暴露到公网，安全组只放行必要端口，比如80和443；
- 启动jar包时加
-Xmx512m限制堆内存，否则云服务器1G内存很容易被吃满； - 用systemd写service文件管理进程，崩溃自动重启；
- 日志不要直接输出到控制台，配一个logback-spring.xml按天滚动。
答辩时老师问起运维部署，你能说出"systemd管理进程、滚动日志、安全组只开必要端口"这些实操细节，比空谈架构强多了。
6.5 Service循环依赖导致启动失败
Spring Boot 2.6开始默认禁止循环依赖，我就碰到过一次：AuctionService里调用了UserService，UserService又反向调用了AuctionService，应用启动直接报错。排查方法很简单，把互相调用的代码拆开，抽出一个公共Service，或者用事件机制解耦。我当时把通知逻辑拆成了独立的NotificationService，问题当场解决，代码结构也清爽了。
最后再分享一个实操中很管用的小技巧。做这种带状态流转的系统，建议单独建一张操作记录表，把关键状态变更的前后值、操作人、操作时间全部记录下来。调试的时候翻一下这张表，能省掉大量"靠猜"的时间。我在答辩演示时被老师当场追问某个字段为什么异常，直接查操作记录表把前后变更看个透，那种从容不是背稿子能装出来的。这个习惯，希望你从一开始写代码就养成。
