企业官网建设流程全解析

简介：本资源为高校计算机专业毕业设计级停车场管理系统完整实现方案，面向软件工程、物联网及智能交通方向的本科生与课程设计学习者，聚焦车位管理、车牌识别、费用结算等核心业务场景。压缩包共592个文件，含89个Java源码（如ParkingRegisterServiceImpl、ParkingServiceImpl等核心服务类）、135个XML配置文件（Spring/MyBatis框架配置）、184个编译后class文件、66个依赖jar包、4个SQL建表与初始化脚本，以及JS/HTML前端页面和properties属性配置，整体达142.93MB，结构覆盖前后端全栈模块。已有2529人学习下载，资源提供可直接运行的完整系统工程，包含车牌识别集成逻辑（基于OpenCV预处理+轻量模型调用）、多表关联数据库设计（车辆、车位、交易三类主表）、RESTful支付接口对接示例及异常报警机制实现代码，是深入理解智能停车系统软硬协同架构与工程落地的优质实践材料。

1. 停车场管理系统：为什么学生交毕设总卡在“车位状态不一致”和“收费算不准”这两关？

你手上的毕业设计任务书写着“实现一个停车场管理系统”，但真正动手时才发现：模拟车辆进场，数据库里车位数减了1；可后台管理界面刷新后还是显示“剩余50个”；更别提高峰期连续进3辆车，系统算出的停车费要么多收5块、要么少收8块——答辩老师一问“你怎么保证数据一致性？”，当场哑火。这不是代码写得烂，而是没把停车场这个场景里的真实约束提前拆解清楚：车位是物理资源，有唯一编号和固定状态（空/占/故障）；计费不是简单按小时四舍五入，要支持分段计费（前30分钟免费、首小时5元、超2小时每半小时3元）、跨天结算、优惠券抵扣；而学生常套用电商购物车那一套CRUD逻辑，直接翻车。这套方案专为课程设计/毕设场景打磨：它不追求高并发百万级吞吐，但死磕状态闭环、计费可验、操作可追溯三个硬指标。适合正在赶DDL、需要一份能跑通+能讲清+能过答辩的完整交付物的同学——从数据库建表语句到收费规则配置表，从进场车牌识别伪代码到离场扣费校验逻辑，全部按真实项目节奏组织，不是拼凑的Demo。

2. 需求拆解与核心约束建模：把“停车”这件事翻译成可落地的数据语言

2.1 车位不是数字，是带生命周期的实体对象

很多同学一上来就建一张parking_lot表，字段只有id,total_count,available_count。这是最大误区。真实停车场里，每个车位是独立个体：A区1号车位可能因地面塌陷停用，B区5号车位支持新能源车充电，C区负二层所有车位夜间禁停。必须用车位主表 + 状态流水表双结构建模：

-- 车位基础信息表（只存静态属性） CREATE TABLE parking_space ( id BIGINT PRIMARY KEY AUTO_INCREMENT, code VARCHAR(20) NOT NULL COMMENT '车位编号，如 A101, B205', area VARCHAR(10) NOT NULL COMMENT '所属区域，A/B/C区', floor TINYINT NOT NULL COMMENT '楼层，-2/-1/0/1/2', type ENUM('standard', 'ev', 'disabled', 'vip') DEFAULT 'standard' COMMENT '车位类型', status ENUM('normal', 'maintenance', 'blocked') DEFAULT 'normal' COMMENT '当前可用状态', created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 车位状态变更流水表（记录每一次状态变化） CREATE TABLE space_status_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, space_id BIGINT NOT NULL, old_status ENUM('empty', 'occupied', 'reserved', 'cleaning') COMMENT '变更前状态', new_status ENUM('empty', 'occupied', 'reserved', 'cleaning') COMMENT '变更后状态', operator_type ENUM('system', 'admin', 'iot_device') COMMENT '操作来源', operator_id VARCHAR(50) COMMENT '操作人ID或设备ID', triggered_at DATETIME DEFAULT CURRENT_TIMESTAMP, note TEXT COMMENT '备注，如“地锁故障手动置空”' );

提示：parking_space.status字段只表示该车位是否允许被分配（如维修中就不能分配），而实时占用状态必须查space_status_log最新一条记录的new_status。这样设计，既支持人工干预（管理员强制修改某车位状态），又保留审计线索——答辩时老师问“怎么证明这个车位确实被占用了？”，你直接查日志表，比口头解释有力十倍。

2.2 计费不是数学题，是规则引擎驱动的状态机

学生最容易写的错是：fee = ceil((exit_time - entry_time) / 3600) * 5。这忽略了三个现实：① 免费时段（前15分钟）；② 分段累进（第1小时5元，第2小时起每半小时3元）；③ 优惠叠加（会员折扣+时段优惠券）。正确做法是把计费规则抽成独立配置表，运行时动态加载：

-- 计费规则主表 CREATE TABLE fee_rule ( id TINYINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL COMMENT '规则名称，如“工作日标准计费”', is_active BOOLEAN DEFAULT TRUE COMMENT '是否启用', priority TINYINT DEFAULT 100 COMMENT '优先级，数值越小越先匹配', created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 规则明细表（一条规则可含多段计费条件） CREATE TABLE fee_rule_detail ( id BIGINT PRIMARY KEY AUTO_INCREMENT, rule_id TINYINT NOT NULL, duration_minutes INT NOT NULL COMMENT '本段持续分钟数，0表示“剩余全部时间”', base_fee DECIMAL(6,2) NOT NULL COMMENT '基础费用', unit_fee DECIMAL(6,2) DEFAULT 0.00 COMMENT '单位费用（如每半小时3元，则填3.00）', unit_duration_minutes INT DEFAULT 0 COMMENT '单位时长（分钟）', free_threshold_minutes INT DEFAULT 0 COMMENT '免收阈值（如15）', discount_rate DECIMAL(4,3) DEFAULT 1.000 COMMENT '折扣率，0.95=95折', min_fee DECIMAL(6,2) DEFAULT 0.00 COMMENT '本段最低收费', max_fee DECIMAL(6,2) DEFAULT 9999.99 COMMENT '本段最高收费', sort_order TINYINT DEFAULT 0 COMMENT '执行顺序' ); -- 示例：插入“工作日标准规则”（前15分钟免费，首小时5元，之后每半小时3元） INSERT INTO fee_rule (name, is_active, priority) VALUES ('workday_standard', TRUE, 10); INSERT INTO fee_rule_detail (rule_id, duration_minutes, base_fee, unit_fee, unit_duration_minutes, free_threshold_minutes, sort_order) VALUES (1, 60, 0.00, 0.00, 0, 15, 1), -- 前15分钟免费（base_fee=0且free_threshold=15） (1, 60, 5.00, 0.00, 0, 0, 2), -- 第1小时固定收5元 (1, 0, 0.00, 3.00, 30, 0, 3); -- 剩余时间按每半小时3元累加

计费逻辑不再硬编码，而是运行时根据车辆入场时间、离场时间、车牌类型（是否VIP）、是否使用优惠券，匹配最优先级的激活规则，再逐条计算明细。这样改规则不用动代码，改数据库就行——答辩演示时，你当场在后台把“夜间22:00-6:00半价”规则启用，系统立刻生效，比写100行if-else更有说服力。

2.3 车辆进出不是API调用，是带防重与幂等的事务链

学生常写两个接口：POST /car/in和POST /car/out。但真实场景中，地感线圈可能误触发两次进场信号，摄像头识别失败导致人工补录，甚至网络抖动造成重复请求。必须设计防重令牌 + 状态校验 + 补单机制：

• 进场时，前端生成UUID作为request_id，后端存入Redis（有效期2小时），同时检查该车牌在current_parking_record表中是否存在status='in'的未出场记录；
• 出场时，必须传入进场时返回的record_id，且校验该记录status确为in，否则拒绝；
• 若因网络问题导致出场请求丢失，提供“补录出场”管理端功能，需输入车牌+进场时间范围，系统自动匹配并校验（如该车确实在场内，才允许补录）。

这种设计让系统具备“业务容错”能力，而不是靠“祈祷别出错”。你在答辩PPT里放一张“异常场景处理流程图”，比堆砌10个正常用例更显工程素养。

3. 总体架构设计：三层结构与四个模块的职责划分

3.1 架构选型：为什么放弃Spring Cloud，坚持单体分层？

看到“管理系统”就上微服务？那是给日活百万的SaaS平台准备的。你的毕设部署环境大概率是导师实验室一台8G内存的旧服务器，或者自己笔记本跑Docker。强行拆服务，光Eureka注册中心+Gateway网关就吃掉2G内存，最后连前端页面都打不开。本方案采用经典MVC分层单体架构，但分层比教科书更狠：

• Controller层：只做参数校验、请求路由、统一异常包装（返回标准JSON格式），零业务逻辑；
• Service层：严格按业务域切分，ParkingService管车位状态流转，FeeCalculationService只负责读规则表+算钱+返回明细，RecordService管进出记录全生命周期；
• DAO层：MyBatis XML写SQL，杜绝@Select("select * from xxx")式懒写法；每个查询明确标注@SelectKey或<resultMap>，确保字段映射可控；
• 额外加一层Domain层：定义ParkingRecord、FeeDetail等POJO，所有Service方法入参出参都用Domain对象，禁止DTO满天飞。

这样做的好处是：代码目录结构清晰（/controller,/service/parking,/service/fee,/dao,/domain），答辩老师扫一眼包路径就知道你懂分层；更重要的是，后续如果真要升级微服务，只需把/service/parking整个包拎出来，就是天然的服务边界。

3.2 四大核心模块与数据流向

系统不是一堆表和接口的集合，而是四个角色协同工作的有机体：

数据流不是单向箭头，而是环形闭环：车辆进场 → 分配车位 → 记录在场 → 出场触发计费 → 扣费成功 → 归档记录 → 统计报表更新 → 管理员看板刷新。你在画架构图时，把这四个模块画成齿轮咬合状，比画一堆虚线箭头更直观。

3.3 数据库设计：三张核心表与两个关键索引

毕设数据库常犯的错是：表建了一堆，但慢查询频发。本方案只聚焦三张核心业务表，并为高频查询配好索引：

-- 1. 停车记录主表（核心！） CREATE TABLE parking_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, plate_number VARCHAR(10) NOT NULL COMMENT '车牌号', in_time DATETIME NOT NULL COMMENT '进场时间', out_time DATETIME NULL COMMENT '出场时间', space_id BIGINT COMMENT '占用车位ID', status ENUM('in', 'out', 'abandoned') DEFAULT 'in' COMMENT '当前状态', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_plate_in (plate_number, in_time), -- 查某车历史记录 INDEX idx_in_out (in_time, out_time) -- 查某时段所有出场记录（报表用） ); -- 2. 费用明细表（与记录表1:1，避免在parking_record里加一堆fee字段） CREATE TABLE fee_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, record_id BIGINT NOT NULL COMMENT '关联parking_record.id', rule_id TINYINT NOT NULL COMMENT '所用计费规则ID', total_fee DECIMAL(8,2) NOT NULL COMMENT '应收总额', actual_fee DECIMAL(8,2) NOT NULL COMMENT '实收金额', discount_amount DECIMAL(8,2) DEFAULT 0.00 COMMENT '优惠金额', payment_method ENUM('cash', 'wechat', 'alipay', 'monthly_card') COMMENT '支付方式', paid_at DATETIME NULL COMMENT '支付时间', UNIQUE KEY uk_record_id (record_id) -- 强制1:1关系 ); -- 3. 车位状态日志表（前面已建，此处强调索引） -- 在space_status_log表上建复合索引： -- INDEX idx_space_time (space_id, triggered_at) -- 查某车位所有状态变更 -- INDEX idx_time_status (triggered_at, new_status) -- 查某时段所有状态变更（运维用）

注意：parking_record表的idx_plate_in索引是救命索引。没有它，查“京A12345昨天停了几次”要全表扫描；有了它，毫秒级响应。答辩时老师让你现场演示查某车牌历史，你敲完SQL回车，0.012秒出结果，比说一百遍“我用了索引”都管用。

4. 关键模块实现：从进场分配到离场扣费的完整代码链

4.1 进场分配：如何在300ms内找到一个可用车位？

学生常写循环遍历所有车位，挨个查status='empty'，数据量一过千就卡死。正确做法是预计算+缓存穿透防护：

// ParkingService.java public ParkingRecord assignSpaceForIn(String plateNumber) { // 1. 先查该车是否有未出场记录（防重复进场） ParkingRecord existing = parkingRecordMapper.selectActiveByPlate(plateNumber); if (existing != null) { throw new BusinessException("车牌" + plateNumber + "已在场内，请勿重复进场"); } // 2. 从缓存获取A区空闲数（key: space_available_count:A） String cacheKey = "space_available_count:" + defaultArea; Integer availableCount = (Integer) redisTemplate.opsForValue().get(cacheKey); // 3. 缓存为空？说明刚启动或缓存失效，走DB兜底并重建缓存 if (availableCount == null || availableCount <= 0) { availableCount = rebuildAvailableCountCache(defaultArea); } // 4. 空闲数为0？直接报错，不查DB（保护数据库） if (availableCount <= 0) { throw new BusinessException("区域" + defaultArea + "暂无空闲车位"); } // 5. 真正分配：用数据库行锁保证原子性（关键！） // 先查一个空闲车位（按code升序，保证每次选同一个） ParkingSpace space = parkingSpaceMapper.selectOneEmptyByArea(defaultArea); if (space == null) { // 极小概率：缓存和DB不一致，再次重建缓存后重试一次 rebuildAvailableCountCache(defaultArea); space = parkingSpaceMapper.selectOneEmptyByArea(defaultArea); if (space == null) { throw new BusinessException("车位分配失败，请稍后重试"); } } // 6. 更新车位状态（带版本号乐观锁 or 直接UPDATE ... WHERE status='empty'） int updated = parkingSpaceMapper.updateStatusToOccupied(space.getId(), "empty", "occupied"); if (updated != 1) { // 被其他请求抢先占用了，递归重试（最多2次） return assignSpaceForIn(plateNumber); } // 7. 写入停车记录 ParkingRecord record = new ParkingRecord(); record.setPlateNumber(plateNumber); record.setInTime(new Date()); record.setSpaceId(space.getId()); record.setStatus("in"); parkingRecordMapper.insert(record); // 8. 写入状态日志 SpaceStatusLog log = new SpaceStatusLog(); log.setSpaceId(space.getId()); log.setOldStatus("empty"); log.setNewStatus("occupied"); log.setOperatorType("iot_device"); spaceStatusLogMapper.insert(log); // 9. 更新缓存（空闲数-1） redisTemplate.opsForValue().decrement(cacheKey); return record; }

这段代码的价值不在语法，而在每一行背后的决策：第2步用缓存挡掉90%的DB查询；第4步用rebuildAvailableCountCache()兜底，其内部是SELECT COUNT(*) FROM parking_space WHERE area=? AND status='normal' AND id IN (SELECT space_id FROM space_status_log WHERE new_status='empty' GROUP BY space_id)；第6步用UPDATE ... WHERE status='empty'而非先SELECT再UPDATE，避免竞态；第9步缓存更新必须在DB事务提交后执行（本例因无显式事务，故放在最后）。这些细节，才是答辩时老师想听的“你为什么这么写”。

4.2 计费引擎：动态规则解析与费用明细生成

FeeCalculationService.calculateFee()方法必须返回可验证的明细，不能只返回一个数字：

// FeeCalculationService.java public FeeCalculationResult calculateFee(Long recordId, Date exitTime, String couponCode) { // 1. 加载原始记录 ParkingRecord record = parkingRecordMapper.selectById(recordId); if (record.getOutTime() != null) { throw new BusinessException("该记录已出场，不可重复计费"); } // 2. 计算停车时长（分钟） long minutes = TimeUnit.MILLISECONDS.toMinutes(exitTime.getTime() - record.getInTime().getTime()); // 3. 匹配计费规则（按priority升序查，取第一个is_active=true的） FeeRule activeRule = feeRuleMapper.selectFirstActiveRule(); if (activeRule == null) { throw new BusinessException("未找到启用的计费规则"); } // 4. 加载规则明细（按sort_order排序） List<FeeRuleDetail> details = feeRuleDetailMapper.selectByRuleId(activeRule.getId()); // 5. 逐段计算（核心逻辑） BigDecimal totalFee = BigDecimal.ZERO; BigDecimal discountAmount = BigDecimal.ZERO; List<FeeDetailItem> items = new ArrayList<>(); long remainingMinutes = minutes; for (FeeRuleDetail detail : details) { if (remainingMinutes <= 0) break; long currentSegmentMinutes = detail.getDurationMinutes() == 0 ? remainingMinutes : Math.min(detail.getDurationMinutes(), remainingMinutes); // 免费阈值处理 if (detail.getFreeThresholdMinutes() > 0 && currentSegmentMinutes <= detail.getFreeThresholdMinutes()) { items.add(new FeeDetailItem("免费时段", 0, 0)); remainingMinutes -= currentSegmentMinutes; continue; } // 基础费用 BigDecimal segmentFee = BigDecimal.valueOf(detail.getBaseFee()); // 单位费用累加（如每半小时3元） if (detail.getUnitFee().compareTo(BigDecimal.ZERO) > 0 && detail.getUnitDurationMinutes() > 0) { long units = (long) Math.ceil((double) currentSegmentMinutes / detail.getUnitDurationMinutes()); segmentFee = segmentFee.add(detail.getUnitFee().multiply(BigDecimal.valueOf(units))); } // 本段最低/最高限制 if (segmentFee.compareTo(BigDecimal.valueOf(detail.getMinFee())) < 0) { segmentFee = BigDecimal.valueOf(detail.getMinFee()); } if (segmentFee.compareTo(BigDecimal.valueOf(detail.getMaxFee())) > 0) { segmentFee = BigDecimal.valueOf(detail.getMaxFee()); } items.add(new FeeDetailItem( detail.getDurationMinutes() == 0 ? "超出时段" : "第" + (items.size()+1) + "段", currentSegmentMinutes, segmentFee.doubleValue() )); totalFee = totalFee.add(segmentFee); remainingMinutes -= currentSegmentMinutes; } // 6. 应用优惠券（简化版：直接减固定金额） if (StringUtils.isNotBlank(couponCode)) { Coupon coupon = couponMapper.selectByCode(couponCode); if (coupon != null && coupon.getValidUntil().after(new Date())) { discountAmount = BigDecimal.valueOf(coupon.getDiscountAmount()); totalFee = totalFee.subtract(discountAmount).max(BigDecimal.ZERO); } } // 7. 构建结果（含明细，可打印小票） return new FeeCalculationResult( recordId, totalFee.doubleValue(), discountAmount.doubleValue(), items ); }

设计说明：FeeDetailItem对象包含“描述、时长、费用”三要素，最终可渲染成小票样式：“前15分钟：免费；第1小时：5.00元；第2小时起（32分钟）：6.00元；优惠券抵扣：2.00元；合计：9.00元”。答辩时你打开管理后台，输入任意一辆车的record_id和模拟离场时间，系统立刻生成带明细的PDF小票——这比你说“我实现了计费功能”震撼十倍。

4.3 离场扣费：事务一致性与异常补偿

出场不是简单update，而是跨表、跨状态、带资金流的强一致性操作：

// RecordService.java （使用@Transactional注解） @Transactional(rollbackFor = Exception.class) public void completeOut(Long recordId, Double actualFee, String paymentMethod) { // 1. 查询记录（必须是in状态） ParkingRecord record = parkingRecordMapper.selectById(recordId); if (!"in".equals(record.getStatus())) { throw new BusinessException("记录状态非'in'，无法出场"); } // 2. 计算应收费用（复用FeeCalculationService） FeeCalculationResult result = feeCalculationService.calculateFee(recordId, new Date(), null); // 3. 校验实收金额（防人工输错） if (Math.abs(actualFee - result.getTotalFee()) > 0.01) { throw new BusinessException("实收金额" + actualFee + "与应收费用" + result.getTotalFee() + "不符，请核对"); } // 4. 更新停车记录状态 record.setOutTime(new Date()); record.setStatus("out"); parkingRecordMapper.updateById(record); // 5. 写入费用明细 FeeRecord feeRecord = new FeeRecord(); feeRecord.setRecordId(recordId); feeRecord.setRuleId(result.getRuleId()); feeRecord.setTotalFee(result.getTotalFee()); feeRecord.setActualFee(actualFee); feeRecord.setDiscountAmount(result.getDiscountAmount()); feeRecord.setPaymentMethod(paymentMethod); feeRecord.setPaidAt(new Date()); feeRecordMapper.insert(feeRecord); // 6. 释放车位（更新状态日志 + 缓存） SpaceStatusLog log = new SpaceStatusLog(); log.setSpaceId(record.getSpaceId()); log.setOldStatus("occupied"); log.setNewStatus("empty"); log.setOperatorType("system"); spaceStatusLogMapper.insert(log); // 更新缓存：对应区域空闲数+1 String cacheKey = "space_available_count:" + getAreaBySpaceId(record.getSpaceId()); redisTemplate.opsForValue().increment(cacheKey); // 7. 发送归档完成事件（供报表模块消费） eventPublisher.publishEvent(new RecordArchivedEvent(recordId)); }

这段代码的精华在@Transactional和第3步的金额校验。它确保：如果第5步写fee_record失败，整个事务回滚，parking_record不会被错误标记为out，车位也不会被错误释放。而金额校验是最后一道防线——哪怕前端传错数，后端也拦得住。这种“宁可失败也不将就”的设计哲学，正是工程能力的体现。

5. 常见问题排查：学生毕设最易翻车的5个点及血泪解法

5.1 现象：后台显示“剩余车位50”，但实际去停车场发现全满了

原因：缓存（Redis）中的空闲数与数据库状态不同步。常见于两种情况：① 系统重启后缓存为空，但未触发重建；② 人工在数据库直接UPDATE了parking_space.status，却忘了更新缓存。
解决：

• 启动时强制调用rebuildAvailableCountCache()初始化所有区域缓存；
• 所有修改车位状态的操作（包括管理后台的“强制置空”按钮），必须走ParkingService.changeSpaceStatus()方法，该方法内部会同步更新缓存；
• 在管理后台加一个“缓存诊断”按钮，点击后对比缓存值与DB实时COUNT值，差异>5%则标红告警。

5.2 现象：同一辆车连续进场两次，系统生成两条status=in记录

原因：进场接口未做幂等性校验，地感线圈抖动或网络重试导致重复请求。
解决：

• 前端每次进场请求必须携带唯一request_id（UUID）；
• 后端用redisTemplate.opsForValue().setIfAbsent("in_request:" + requestId, "1", Duration.ofHours(1))做防重；
• 若setIfAbsent返回false，直接返回{"code":409,"msg":"重复请求"}，不查DB不写日志。

5.3 现象：离场时系统报错“找不到该记录”，但数据库里明明有

原因：parking_record表的plate_number字段未加索引，当数据量>1万时，select * from parking_record where plate_number='京A12345' and status='in'执行超时（MySQL默认30秒），连接池耗尽。
解决：

• 立即执行ALTER TABLE parking_record ADD INDEX idx_plate_status (plate_number, status);；
• 在ParkingRecordMapper.xml中，所有涉及plate_number的查询，WHERE条件必须同时带上status（如AND status = #{status}），确保走联合索引。

5.4 现象：修改计费规则后，老记录重新计算费用，结果变了

原因：计费逻辑硬编码在Service里，新规则只影响新记录。但业务要求：已出场未缴费的老记录，按最新规则补算。
解决：

• fee_record表增加rule_version字段，记录计算时使用的规则版本号（如v20240501）；
• FeeCalculationService.calculateFee()方法增加forceUseRuleVersion参数，管理后台“补算费用”时传入最新版本；
• 补算时，先查原fee_record，若rule_version不匹配，则按新规则重算并更新fee_record。

5.5 现象：导出月度报表时，MySQL CPU飙升到100%，页面卡死

原因：报表SQL写成SELECT * FROM parking_record WHERE in_time BETWEEN ? AND ?，没走索引，全表扫描百万行。
解决：

• 在parking_record表上建组合索引：INDEX idx_in_time_status (in_time, status)；
• 报表查询必须用WHERE in_time >= ? AND in_time <= ? AND status = 'out'（status值固定，才能命中索引）；
• 对超大数据量（>10万条/月），启用分页导出：前端选日期后，后端先SELECT COUNT(*)，若>5万，提示“数据量过大，将分批次导出”，每次查5000条写入Excel流。

提示：这5个问题，我在带三届学生毕设时，至少有20人栽在其中某一条。它们不是“技术难点”，而是“工程盲区”——知道索引重要，但不知道不加索引在报表场景下有多致命；知道事务重要，但不知道幂等性是分布式系统的呼吸机。把这些坑列出来，不是为了吓唬你，而是告诉你：毕设过关的关键，不在于写出多炫的算法，而在于堵住这些会让系统在演示时当场崩掉的缝。

6. 答辩验收指南：用三张表、两份日志、一个演示脚本拿下高分

6.1 答辩前必验的三张核心表（现场打开数据库执行）

别等老师问才查，答辩开始前5分钟，自己连上数据库，对着这三张表快速过一遍，确保数据干净、索引到位、状态自洽：

这三张表就是你的“答辩定心丸”。只要它们数据合理，老师就不会质疑系统基本功能。我带过的某同学，答辩前发现parking_record里有10条status='in'但out_time不为空的脏数据，当场用UPDATE parking_record SET out_time=NULL WHERE status='in' AND out_time IS NOT NULL修复——老师全程看着，反而觉得他熟悉生产问题处理。

6.2 两份关键日志：证明系统不是Demo，而是可运维的工程

答辩PPT里不要放100行代码，放两张日志截图，胜过千言万语：

• 第一份：space_status_log最近10条
  截图重点标出：operator_type='iot_device'（证明自动识别）、operator_type='admin'（证明人工干预）、new_status='cleaning'（证明支持保洁流程）。告诉老师：“这张表记录了每一个车位每一次状态变化，无论是机器还是人操作，都有迹可循。”

• 第二份：fee_record中一条带明细的记录
  截图展示total_fee=12.00，旁边列出明细：[{"desc":"前15分钟","fee":0},{"desc":"第1小时","fee":5},{"desc":"第2小时起（42分钟）","fee":6},{"desc":"时段优惠","fee":-1}]。告诉老师：“费用不是拍脑袋算的，每一笔都可拆解、可验证、可审计。”

6.3 一个黄金演示脚本：5分钟讲清全流程

别按“登录-点击-跳转”演示，用这个脚本，把技术深度藏在操作背后：

1. 开场（30秒）：“老师好，我将用5分钟，带您走一遍停车场最核心的‘车辆进场→分配车位→离场计费’闭环。重点展示三个设计：状态一致性、计费可验证、操作可追溯。”
2. 进场演示（1分钟）：
   • 在管理后台“人工登记”输入车牌粤B88888，点击进场；
   • 切换到数据库Tab，执行SELECT * FROM parking_record WHERE plate_number='粤B88888'，指出status='in'、space_id=101；
   • 切换到space_status_log，执行SELECT * FROM space_status_log WHERE space_id=101 ORDER BY triggered_at DESC LIMIT 1，指出new_status='occupied'。
3. 计费演示（2分钟）：
   • 在后台找到该记录，点击“模拟离场”，输入时间2024-05-20 14:30:00；
   • 系统弹出小票窗口，放大展示明细：“前15分钟：0元；第1小时：5元；第2小时起（35分钟）：6元；合计：11元”；
   • 点击“导出PDF”，打开生成的小票，指着二维码说：“这是微信支付沙箱码，扫码即完成支付。”
4. 归档验证（1分钟）：
   • 切回数据库，执行SELECT * FROM fee_record WHERE record_id=(SELECT id FROM parking_record WHERE plate_number='粤B88888' AND status='out');，指出actual_fee=11.00；
   • 执行SELECT * FROM space_status_log WHERE space_id=101 ORDER BY triggered_at DESC LIMIT 2，指出第二条记录new_status='empty'。
5. 收尾（30秒）：“整个过程，状态变更有日志、费用计算有明细

本文还有配套的精品资源，点击获取