去了就了了如果你准备做一个基于SSM的生产设备信息管理系统，无论作为毕业设计还是工厂实训项目，都值得先把问题想透再动手。SSM框架，也就是Spring、Spring MVC和MyBatis三件套，在Java Web开发里已经是非常经典的组合，它的价值不在于“新”，而在于把后端逻辑拆解得明明白白：Spring管对象和事务，Spring MVC管请求路由，MyBatis管数据库访问。而“生产设备信息管理”这个业务，表面只是维护设备数据，实际上牵扯到台账、点检、保养、维修、备件、报表的完整闭环，足够把SSM的每一层都用起来，也能让做项目的人在过程中真正理解框架怎么协调运转。
这个项目适合谁参考呢？一类是正在选毕设题目的同学，另一类是需要在企业内部做小型设备管理工具但不想直接套低代码平台的开发人员。前者可以通过它掌握SSM项目从零搭建的过程，后者可以参考它的表结构和业务流设计思路，快速落地一个能用的管理后台。我会把整个系统的设计思路、数据库结构、核心代码实现和踩过的问题全部整理出来，这篇文章基本就是一套能直接照着走的实操复盘。
1. 项目需求与整体设计思路
1.1 设备管理的真实痛点
我见过不少制造型企业的设备管理方式：设备台账在Excel里，点检记录写在纸质表格上，维修过程靠维修工微信群里发消息，备件有没有库存全凭库管员的脑子。这种模式有很明显的毛病。台账一旦多人修改就会版本混乱，纸质点检表过了几个月想追溯某个设备到底检没检、有没有异常，翻资料极其痛苦。维修工单不数字化，设备故障平均响应时间根本统计不出来，备件更换记录也容易断档，后面做设备寿命分析时没有任何数据支撑。
所以这个系统在设计之初就定了几个核心目标：第一，把设备从入厂到报废的全部档案信息统一收口，让每台设备有唯一的电子身份证；第二，把点检和保养计划落地成可以提醒、可以记录、可以查询的任务流，避免“该检没检、检了没记录”的问题；第三，让维修工单从提交、派单、处理到验收形成闭环，每一步都留痕；第四，能基于这些数据生成基础报表，让管理者看到设备利用率、故障率、维修成本这些关键指标。
1.2 用户角色与权限边界
系统按实际使用场景拆成了三类角色。设备操作员是最日常的使用者，负责查看自己负责的设备信息、提交点检记录、发起维修申请。设备维修员负责接收维修工单、填写维修过程和更换备件明细，维护保养计划执行情况。系统管理员权限最大，负责设备台账管理、用户分配、参数配置、数据统计导出。有些场景下还会拆出班组长角色做工单审核，但在毕设和企业小型系统中，我会把工单审核放在管理员或维修主管这层来做，不必过度设计。
做权限设计时我强烈建议直接用前面提到的Spring MVC拦截器加自定义注解方式，而不要一上来就引入Shiro或Spring Security。虽然它们功能更强大，但对一个SSM项目来说，配置成本和理解成本都不小，尤其毕业设计答辩时被问到“权限怎么实现的”，你说用的是自定义拦截器，反而能展示你对请求链路和Session机制的理解。实际实现中，用户登录后把用户对象放进Session，拦截器拦截需要登录的路径，再从数据库里查出用户对应的菜单权限，渲染页面时只显示有权限的入口就行。
1.3 技术方案选型考量
选SSM这套栈，很关键的一点是它够“裸”、够清晰。Spring的IoC容器负责装配Service和Mapper，MyBatis负责把SQL写在XML里让字段映射可见，Spring MVC作为控制层接收参数并返回视图或JSON。相比起Spring Boot的自动配置，SSM要求手动管理数据源、事务管理器、Mapper扫描路径、视图解析器，这恰恰是学习框架原理的好机会。我在带项目时经常告诉组里的同学，不要嫌SSM配置麻烦，等你自己把applicationContext.xml和spring-mvc.xml从空文件写到一个能跑通增删改查的时候，你对Spring容器的理解会比背十遍面试题都牢。
系统结构上，我采用了经典的分层架构，页面层使用JSP加JSTL做服务端渲染。前后端分离固然是趋势，但在毕设这种规模和演示场景下，服务端渲染能让整体项目更集中，少一层跨域和Token校验的成本。如果担心页面观感不够现代，可以在JSP中引入Vue或Element UI做局部交互，只把页面放在WebContent下，其余代码结构保持不变。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库设计，设备表是第一优先级
2.1 实体关系怎么梳理
我在设计表结构前的习惯是先画实体关系草图，而不是急着建表，这里不用画图工具，用文字理也行。设备管理系统的核心实体是设备，围绕设备衍生出设备类型、设备台账、点检项目、点检记录、保养计划、保养记录、维修工单、维修明细、备件信息、用户等实体。它们之间的关系不复杂：一个设备类型下有多台设备，一台设备会有点检计划也有点检记录，维修工单可以关联设备并引用备件。
设计这个系统最容易犯的错误是拼命往一张大表里塞字段，把点检结果、维修过程、保养记录全部以冗余字段的形式挂在设备表后面。这样做一旦同一台设备需要记录多条维修记录，表结构就崩了。正确做法是坚持一个设备主表加上多个业务子表的设计，业务表通过device_id外键关联设备表，这样不同业务域的数据互不干扰，也容易按时间范围做统计查询。
2.2 核心表结构说明
设备台账表是最主要的主数据表，我建议字段尽可能覆盖设备的静态信息和动态状态信息。静态信息包括设备编号、设备名称、规格型号、生产厂商、出厂编号、购置日期、投入使用日期等。动态信息主要是当前状态，比如运行中、停机、维修中、报废，这个状态会随着工单流程变更，不建议在业务表里到处维护，统一放在设备表状态字段里会更好查询。
sql复制CREATE TABLE device (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
device_code VARCHAR(50) NOT NULL COMMENT '设备编号',
device_name VARCHAR(100) NOT NULL COMMENT '设备名称',
model VARCHAR(100) COMMENT '规格型号',
manufacture VARCHAR(100) COMMENT '生产厂商',
factory_no VARCHAR(100) COMMENT '出厂编号',
buy_date DATE COMMENT '购置日期',
use_date DATE COMMENT '投入使用日期',
location VARCHAR(200) COMMENT '安装位置',
dept_id BIGINT COMMENT '使用部门',
device_type_id BIGINT COMMENT '设备类型',
status TINYINT DEFAULT 1 COMMENT '1运行 0停机 2维修 3报废',
remark VARCHAR(500),
create_time DATETIME,
update_time DATETIME,
KEY idx_device_type (device_type_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
点检表是另一组容易被忽略但工作量很大的表。我把点检拆成点检标准和点检记录两张表。点检标准表维护“转轴是否正常”“液压油位是否在刻度内”这类检查项以及检查方式、标准值。点检记录表记录某一次点检任务中每一个点检项的实测值和结果，只有用这种明细表，才能回答“这台设备的液压系统过去三个月有多少次油位异常”这类问题。如果不拆明细，只在点检主表里存几个拼接好的字符串，统计功能会非常难写。
维修模块通常包含维修工单主表和维修备件明细表。主表需要保存设备ID、报修人、报修时间、故障描述、维修人、受理时间、维修内容、完成时间、验收意见、处理状态等。备件明细表保存这次维修用了哪些备件、数量多少、单价多少，这笔明细可以联动更新备件库存表。
2.3 数据库设计的几个提醒
每张表必须包含主键、创建时间与更新时间。这句话听起来像废话，但我见过大量新手代码里业务表没时间字段，导致后面做统计报表根本没有时间维度可以用。状态字段值建议定义成有意义的数字或英文描述，而且应该在代码里写成枚举或常量，不要散落在业务逻辑里出现裸数字1、2、3。所有金额、数量字段要注意类型选择，数量可以用INT，涉及成本金额用DECIMAL(10,2)，不要用FLOAT。
设备编号是业务唯一性最强的字段，在代码层要校验重复，在数据库层也要加唯一索引。这个是我在实际项目中踩过的坑，录入设备时没加索引，两台设备用了相同编号，后面做故障追溯时数据彻底乱了。另外外键要不要物理创建，我建议不要一味的依赖数据库物理外键，逻辑外键加索引的方式更灵活，尤其SSM项目里删除级联多由业务代码控制，物理外键会在批量导入和删除时带来额外限制。
3. 功能模块与核心业务流设计
3.1 六大功能模块怎么划分
系统功能一般划分为六大块。系统管理负责用户、角色、菜单；设备管理负责设备台账和设备类型；点检管理负责点检计划配置、点检任务生成和点检记录查询；保养管理负责保养计划和保养记录；维修管理负责报修、派单、维修和验收；统计报表负责故障率、维修及时率、设备台账导出。不要小看统计报表模块，它往往决定系统能不能真正被管理者接受。
每个模块内部按“基础数据维护、业务流程办理、历史记录查询”三个层次展开。以点检管理为例，管理员先维护点检标准和点检计划，系统按日期自动生成点检任务，操作员登录后能看到自己名下的待办点检项，填写点检结果后形成记录留存。这样一层层分下来，功能点之间不会纠缠不清。
3.2 维修工单的闭环状态机
设备报修功能是维修管理的入口。操作员在系统里选择故障设备，填写故障现象和紧急程度，提交后生成维修工单。这里的状态流转，我建议设计成几个清晰的状态：待派单、维修中、待验收、已完成、已关闭。维修主管看到待派单的工单后，可以指派给具体维修人员。维修人员开始维修后填写处理方案，修复后在系统里提交“待验收”，由报修人来确认故障是否真正解决。验收通过后工单自动标记“已完成”，同时把设备状态从“维修中”改回“运行中”。
听起来是不是很顺理成章？但如果有一步没设计好，整个流程就会卡住。步态节点要明确是谁来变更。比如不少项目会允许维修人员直接把自己负责的工单从“待派单”改成“维修中”，这会造成维修主管根本没有派单过程，流程形同虚设。我实现时的做法是给角色绑定操作权限，待派单到维修中必须有维修主管角色身份，维修中到待验收是维修人员的操作，待验收到已完成是报修人或者管理员的操作。必要时在代码里加状态流转校验，避免前端的按钮控制被绕过。
3.3 点检与保养的联动设计
点检计划和保养计划如果只是各自维护记录，价值会大打折扣。我的建议是在设计时把它们放在设备全生命周期管理的大逻辑下。一台新设备上线后，系统管理员根据设备类型和维护手册维护保养周期，比如“每500小时更换液压油”“每三个月检查电控柜”。开机时系统自动检查该设备是否已超过最近一次保养时间，超过正常运行小时数的设备会在操作员登录首页时用醒目标识提醒“该保养了”，但允许管理员设置宽限期，不是一刀切。
点检过程中的异常处理也是这个模块的亮点：当操作员在点检记录中勾选“异常”时，系统自动弹出故障报修单创建入口，并带入设备信息、点检项目和异常描述。这样就把点检这个日常动作和维修工单模块串联起来，减少了操作员在发生故障后再去重复填写信息的负担。
3.4 统计报表怎么做才不被嫌弃
统计报表模块，我采用的思路是多维度汇总并不做过度复杂的图形。常用统计包括设备台账按状态分类汇总、设备故障数量按月趋势统计、维修完成及时率统计、常用备件消耗排行。SQL层面先按时间分组和状态条件count即可，再将查询结果封装到统计数据模型中，传给前端用简单的柱状图、饼图展示。
这里要注意的是，报表SQL要尽量避开大范围的跨表关联嵌套查询。我会先把主表时间范围和条件缩小，再关联子表。数据量一旦大了，不遵循这个原则，页面响应会从毫秒级退化到几秒甚至十秒。如果确实需要在查询中计算毛利或总金额，我会在Java程序中对查询出来的明细结果进行聚合，而不是全部压给一条复杂SQL。
4. SSM配置与核心代码实现
4.1 Spring与MyBatis整合配置文件
从零搭建SSM项目时，第一步是配置Spring管理数据源和MyBatis。我在applicationContext.xml里会写这几段关键内容：开启注解驱动和组件扫描，配置数据源，配置SqlSessionFactoryBean，配置MapperScannerConfigurer，再配置事务管理器并开启注解事务。数据源在开发时可用Druid或者C3P0，我比较习惯用Druid，因为它带监控页面，调试时可以看连接池状态和慢SQL。
xml复制<context:component-scan base-package="com.dev.system" />
<bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource">
<property name="driverClassName" value="com.mysql.jdbc.Driver" />
<property name="url" value="jdbc:mysql://localhost:3306/device_system?useUnicode=true&characterEncoding=utf8" />
<property name="username" value="root" />
<property name="password" value="123456" />
</bean>
<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
<property name="dataSource" ref="dataSource" />
<mapper-locations value="classpath:com/dev/system/mapper/*.xml" />
<property name="typeAliasesPackage" value="com.dev.system.entity" />
</bean>
<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
<property name="basePackage" value="com.dev.system.dao" />
<property name="sqlSessionFactoryBeanName" value="sqlSessionFactory" />
</bean>
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource" />
</bean>
<tx:annotation-driven transaction-manager="transactionManager" />
有个细节容易踩坑：模板标签里的数据库URL必须加上字符编码参数，而且XML中转义字符要写正确，否则中文乱码会在增删改查时全部出现。另一个坑是MapperScannerConfigurer和sqlSessionFactory的初始化顺序，如果配错了会导致启动时Mapper接口找不到，所以建议两个Bean的id都显式写清楚，不要依赖自动生成导致注入混乱。
Spring MVC的配置文件相对简单，主要是开启注解驱动、配置视图解析器、配置静态资源和拦截器。页面文件我放在了WEB-INF/views目录下，这个目录有个好处是直接请求URL无法访问文件内容，必须经过Controller跳转，能避免部分静态文件或JSP源码被直接下载查看。
4.2 Service层业务方法实现
Service层是事务的核心。维修工单的创建更新会同时影响设备表和备件库存表，这个时候就必须使用事务。我用Spring的@Transactional注解标注方法，并设置rollbackFor为Exception.class。默认情况下事务管理在对RuntimeException回滚，如果代码中手动捕获了异常但没有重新抛出，事务就不会正确回滚。我经常看到新人用try-catch包住整个方法，然后catch里只打印日志，最后出现数据不一致还查不到原因。
一段典型Service代码：
java复制@Service
@Transactional(rollbackFor = Exception.class)
public class RepairOrderServiceImpl implements RepairOrderService {
@Autowired
private RepairOrderMapper orderMapper;
@Autowired
private DeviceMapper deviceMapper;
@Autowired
private SparePartStockMapper stockMapper;
@Override
public void createRepairOrder(RepairOrder order, Long deviceId) {
// 1. 插入维修工单
order.setStatus(RepairStatus.PENDING_DISPATCH.getCode());
orderMapper.insert(order);
// 2. 变更设备状态为维修中
Device device = deviceMapper.selectById(deviceId);
if (device == null) {
throw new BusinessException("设备不存在，无法创建维修工单");
}
device.setStatus(DeviceStatus.REPAIRING.getCode());
deviceMapper.updateStatus(device);
}
}
为了可读性我在代码里直接用了BusinessException这个自定义异常，实际项目还需要配合全局异常处理器把异常信息转换成用户友好的提示。Service层最忌讳在里面写大量和业务无关的分页、格式化代码，这部分应该由Controller或者公共工具类负责。
4.3 点检模块中批量生成任务的处理
点检任务生成的方法，本质上就是把“点检计划主表+计划和点检项明细”拼接成一条条待办任务。这里有几种实现方案：最简单的是每次管理员登录时动态生成当日点检任务；常见的是每日凌晨用一个定时器去扫描计划表并生成任务。考虑项目规模不大，我在系统里用了第二种方案，通过Spring自带的@Scheduled定时任务每天执行一次生成任务。如果点检周期为每月或每周，则根据自定义周期计算下次执行时间。
生成点检任务时有一个重要的幂等性问题，也就是同一台设备同一天的同类点检任务不能重复生成。解决办法是查询任务表里是否已经存在“该设备当日该点检类型”的记录，另一种更稳妥的方法是给任务表加联合唯一索引，设备id、日期、计划类型、任务类型组成唯一键，数据库层兜底防重。实际开发中我把这个索引加上了，真遇到一次定时任务跑了两遍的情况，发现虽然服务逻辑已经通过查询过滤，但因为两个线程并发同时走到插入逻辑，最终还是有重复数据，幸亏有唯一索引直接抛错，才帮我及时发现定时任务被重复执行的问题。
4.4 Controller层统一返回结果
传统SSM项目中Controller有时直接返回ModelAndView，接口和页面混在一起。该项目的维修、设备填报等需要异步校验的接口，我使用@ResponseBody返回统一JSON结果结构。为让前端代码简洁，我封装了一个Result类包含code、message、data三个属性，成功时code是0，业务失败时code是业务错误码，不再使用HTTP状态码承载业务错误。这样做的好处是前端只需要判断code字段，不必为每个接口单独写异常处理分支。
java复制@RequestMapping("/device/list")
@ResponseBody
public Result list(DeviceQueryVO query, @RequestParam(defaultValue = "1") int pageNum,
@RequestParam(defaultValue = "10") int pageSize) {
PageHelper.startPage(pageNum, pageSize);
List<DeviceVO> deviceList = deviceService.queryDevicePage(query);
PageInfo<DeviceVO> pageInfo = new PageInfo<>(deviceList);
return Result.success(pageInfo);
}
在这个列表接口里我使用了PageHelper分页插件，这也是SSM项目里很常见的做法。使用它的原则是需要在查询执行前调用PageHelper.startPage，然后紧接着执行Mapper查询，中间不能有任何其他数据库操作，否则PageHelper会把拦截范围扩大，导致分页数据错乱。返回的PageInfo里包含了总条数、总页数等分页信息，前端做表格分页时非常方便。
5. 开发中遇到的高频问题与排查方法
5.1 中文乱码和日期格式问题
中文乱码在SSM项目中体现为两种形式。写入数据库前乱码，多数因为请求参数的编码方式不对或数据库连接串缺少characterEncoding=utf8。页面展示时乱码则可能来自响应头缺Content-Type编码声明。解决思路是从请求入口、Spring字符编码过滤器、数据库连接串、页面ContentType四层逐一加编码配置。为了避免在多个Controller里手动处理编码，我在web.xml里配置了Spring提供的CharacterEncodingFilter，强制UTF-8。这几乎是SSM项目最标准的方案。
日期时间格式问题是另一个高频问题。前端传“2024-05-01 08:30”，后端用Date类型接收时会报格式转换异常或接收为null，原因是Spring默认支持的日期格式不包含这种带横杠和空格的字符串。解决方式是在需要接收的Controller方法参数上加@DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss")，或者全局配置一个日期转换器。我更推荐后者，因为系统中的所有日期字段基本都用统一格式，配置一个全局工具类可以少写大量重复注解。
5.2 MyBatis中条件查询与N+1问题
设备列表页往往需要组合复杂条件查询，如设备名称模糊搜索、购置日期区间、设备状态下拉选择。我在Mapper XML中会使用动态SQL的where和if标签组合生成查询条件。写这种SQL时最需要关注的是空值判断，不只要判断NULL，还要判断空字符串，不然页面没填写任何搜索条件时很容易拼出“AND device_name = ”这种非法SQL。
还有一种常见的性能问题是N+1查询。比如查询维修工单主数据后，逐条查询关联设备信息。项目数据量少时看不出问题，一旦维修工单达到几百条，页面就明显变慢。我解决的方式是先用一条主查询把工单基本数据查出来，再通过IN查询一次性查出多个工单对应的设备信息，然后用Java代码进行内存组装。MyBatis里也可以使用resultMap的collection标签一次查出嵌套数据，但要小心分页插件和嵌套集合在总条数统计上的兼容性。我在项目里一直使用内存组装模式，逻辑直观且性能可接受。
5.3 上传设备图片无法预览
设备管理功能中上传设备照片是一个常见需求。Servlet 3.0原生API支持MultipartFile上传，但配置不当会导致上传失败或预览时图片路径404。问题通常出在静态资源的映射上，如果上传目录在工程目录之外，而Spring MVC又只映射了webapp下的资源，那么图片就无法直接访问。我给系统设置了一个上传目录磁盘路径，并把该路径下的upload映射为静态资源URL。
xml复制<mvc:resources mapping="/upload/**" location="file:D:/upload/" />
生产部署后路径要换成服务器实际存储路径。上传之前最好校验文件类型，只允许jpg、png后缀，同时限制文件大小。我建议在Servlet容器层面的MultipartResolver里设置上传大小上限，避免用户直接上传几百兆的图片占满磁盘。一次上传成功后，保存的路径字段应当是相对路径而不是完整本地路径，这样系统迁移到其他服务器时，不需要把数据表里残留的旧绝对路径全部改一遍。
5.4 设备状态和工单状态不同步
这是设备管理系统里比较隐蔽的逻辑坑。设备报修后我在设备表把状态改成“维修中”，但是维修工单验收完成后必须再把设备改成“运行中”。如果验收业务的代码没有修改设备表状态的逻辑，那设备就一直显示维修中。光靠维修人员手动去改设备状态也不现实，很容易遗忘。
遇到这个问题后，我在状态变更的核心入口抽了个状态机服务，把每一个合法流转和对应动作集中管理。状态机服务方法的命名也能辅助理解上下文的业务关系，比如completeRepairOrder中先校验工单当前状态，再更新工单状态、更新设备状态、扣减备件库存或更新保养记录。这样设备状态、工单状态就再也不会因为遗漏某一行代码而不一致。
6. 测试、部署与后续扩展建议
6.1 功能测试用例应该覆盖哪些重点
作为开发者和项目负责人，我在项目完成前会梳理优先级最高的功能测试用例。所有角色登录登出是基础路径，密码错误要有明确提示。设备台账增删改查中重点关注编号重复校验和分页查询正确性。点检任务生成需要验证周期和幂等性，异常点检项目能否正确触发维修工单。维修流程需要走完整状态链，从报修到派单再到验收。权限测试要以维修员账户登录后尝试访问管理员菜单，接口层面应该返回无权限提示，而不是查出数据。
测试设备表格导出时，建议导入少量数据实测编码格式，导出的Excel用Excel软件打开是否出现列错位或中文乱码。我有一回导出Excel时忘记设置列宽，中文虽然没乱码但列头被截断，观感很差。虽然不影响数据正确性，但对系统演示效果的影响很大，所以这类细节也在验收范围内。
6.2 Tomcat部署和服务端注意事项
项目开发完成后我习惯打WAR包部署在本机Linux虚拟机的Tomcat下。直接复制WAR到webapps目录并启动Tomcat看起来简单，仍然有几个必须检查的点。第一，因为服务器没有图形界面，数据库连接信息要通过环境变量或外部配置文件控制，不要把这套配置硬编译进WAR包里导致无法迁移。第二，在Tomcat的server.xml中添加UTF-8相关的连接配置，尤其是有自定义访问路径的场景。
定时任务部署后有两点要额外注意：服务器时区务必设置为Asia/Shanghai，防止定时任务因为时区偏差在规定时间之外执行。日志文件要配置滚动切割，长时间运行生成的日志会越来越大，我建议在log4j或logback配置里按日期拆分，并定期清理过期日志。生产环境不像本地开发可以随时看控制台，日志排查是唯一手段。
6.3 后续能往哪些方向扩展
设备管理系统是一个非常好的基础框架，按照这个架构继续扩展有两条比较自然的路径。一条是做预测性维护，把设备点检数据、维修记录和传感器采集的数据汇合起来分析，比如通过历史故障数据判断哪些设备在近期更容易出问题，这个方向能结合机器学习和数据分析。另一条是引入二维码挂牌，为每台设备生成唯一二维码，维修工用手机扫码查看设备档案和点检历史，直接通过移动端提交故障工单。这个扩展工作量主要在前端和移动端协同，后端表结构基本可以复用现有设计。
我一直觉得这类系统最见功力的不是代码炫技，而是对业务的理解程度。生产设备信息管理系统听着中庸，真正能做到让操作员愿意填点检单、让维修主管愿意在系统里派单、让管理者能从报表中看到设备健康状态，它就算成功了。根据我做项目的经验，从一开始就把表结构设计清晰、把流程状态收口、把权限边界划清楚，后续维护起来特别省心，踩坑的概率也会小很多。