★ FEATURED ARTICLE 简介本资源是一份面向计算机专业本科生的毕业设计开题报告文档聚焦SpringBootVue技术栈开发的考勤管理系统旨在解决企事业单位及学校中传统考勤效率低、数据不准、统计繁琐等实际管理痛点。报告内容完整覆盖选题背景与意义、国内外研究现状含微服务架构、前后端分离、生物识别集成等前沿方向、系统功能模块员工管理、请假审批、签到统计、薪资与出差管理等及技术实现路径兼具学术规范性与工程实践指导价值。资源为单文件docx格式大小208KB结构清晰、图文结合可直接用于开题答辩或课程设计参考。目前已有62人学习下载适合需快速掌握毕业设计选题逻辑、技术选型依据与系统化文档撰写的初/中级开发者与应届生。1. 为什么一个“考勤系统”开题报告能被导师当场打回三次不是因为功能不全也不是因为技术栈过时——而是学生交上来的是“功能清单堆砌”而导师要的是可落地、可答辩、可复现的工程闭环逻辑。我带过三届毕设见过太多同学把“员工管理、请假审批、考勤统计”列成 bullet point 就以为设计完成了。结果答辩现场被问“请假流程里审批人是固定角色还是动态指派驳回后数据状态怎么回滚前端表单提交失败用户刷新页面会不会重复提交”——当场卡壳。这份《SpringBoot考勤管理系统》开题报告之所以值得细读正因为它没停留在“我要做啥”而是用真实项目节奏倒推从多校区场景下打卡延迟容忍阈值≤3s、到微信小程序扫码签到与后台JWT Token续期策略耦合点、再到MySQL中考勤记录表的联合索引设计如何避免凌晨统计任务锁表——每个模块都带着约束条件在设计。它适合两类人一是正在写开题、被导师反复要求“补充技术细节”的本科生二是需要快速交付一套轻量级考勤MVP给中小客户的开发者。它不吹“AI智能排班”但能把“请假单状态机流转”和“考勤异常标记规则引擎”写进数据库字段注释里。这才是能过审、能跑通、能讲清楚的方案起点。2. 总体架构设计前后端分离下的四层职责划分与数据流向控制2.1 四层结构定义为什么必须砍掉“Controller → Service → Mapper”之外的任意中间层很多同学在开题里写“采用MVC三层架构”但实际代码里塞了 DTO、VO、BO、QO 六七种对象最后连自己都分不清哪个该校验、哪个该持久化。本方案强制约定仅四层Web 层只做请求接收、参数校验JSR-303、统一异常包装ControllerAdvice不处理业务逻辑Service 层严格按用例切分如LeaveApplyService专管请假申请全流程禁止跨用例调用Mapper 层仅含 MyBatis XML 中的select/update标签禁止在 XML 里写复杂 SQL 函数或子查询所有计算逻辑上提至 ServiceDomain 层实体类Entity与数据库表一一映射字段名、类型、长度、是否允许 NULL 必须与建表语句完全一致连注释都要同步后续验收会核对。提示开题报告里常写的“引入 Redis 缓存提升性能”在本方案中被明确限制为仅用于两种场景① 登录态 Token 的分布式存储配合 JWT 的jti字段做黑名单② 考勤日报生成前的临时聚合结果缓存TTL2h避免重复计算。其他任何“为了用而用”的缓存设计在答辩时会被视为架构失控。2.2 前后端接口契约RESTful 不是口号是字段级的军规Vue 前端与 SpringBoot 后端的协作本质是JSON Schema 级别的契约。本方案拒绝“后端返回data字段套一层再套一层”的玄学封装强制所有接口遵循以下结构{ code: 200, message: 操作成功, data: { id: 1001, employeeName: 张三, status: APPROVED, applyTime: 2025-04-05T09:30:00 } }关键约束code必须为 HTTP 状态码映射200成功400参数错误401未登录403无权限500服务异常message仅用于前端 Toast 提示禁止包含技术细节如 “SQLSyntaxErrorException”data字段类型必须与 Swagger 文档声明一致例如请假列表接口的data是ListLeaveVO而单条详情是LeaveVO所有日期字段统一为 ISO 8601 格式yyyy-MM-ddTHH:mm:ss禁止使用Date对象直接序列化必须通过JsonFormat(pattern yyyy-MM-ddTHH:mm:ss)注解固化。这个契约直接决定了前端 Axios 拦截器的编写方式——你不需要在每个.then()里手动解包response.data.data而是全局配置响应拦截器自动剥离外层// utils/request.js service.interceptors.response.use( response { const { code, message, data } response.data; if (code 200) { return Promise.resolve(data); // 直接返回业务数据 } else { ElMessage.error(message); return Promise.reject(new Error(message)); } } );这样做的好处是当后端修改某个接口返回结构时前端所有调用处会因 TypeScript 类型检查立即报错而不是等运行时才发现data.list变成了data.items。2.3 数据流向控制从“员工打卡”到“日报生成”的七步原子操作考勤系统最怕数据不一致——比如员工已打卡但统计报表里没体现。本方案将核心业务流拆解为不可分割的七步原子操作每步失败必须触发完整回滚设备指纹采集小程序端调用wx.getSystemInfoSync()获取modelsystemplatform生成设备唯一标识非 UUID与员工 ID 绑定存入 RedisTTL7d时间戳校验后端接收请求时对比 NTP 服务器时间ntp.timeapi.org若客户端时间偏差 ±30s拒绝打卡并返回code400地理围栏验证调用高德 Web API 校验经纬度是否在预设考勤点 500 米范围内需提前在管理后台配置坐标考勤规则匹配根据员工所属部门、岗位、当日排班表查出适用的打卡时段如“9:00-9:30 为早班打卡”状态机更新在 MySQL 中执行UPDATE attendance_record SET statusCHECKED_IN, check_timeNOW() WHERE employee_id1001 AND date2025-04-05 AND statusNOT_CHECKED利用 WHERE 条件保证幂等性事件发布通过 Spring Event 发布CheckInSuccessEvent由监听器异步触发① 更新员工今日考勤状态缓存② 若为首次打卡发送企业微信通知日报触发每日 00:05Quartz 定时任务扫描attendance_record表中date yesterday且statusNOT_CHECKED的记录批量生成attendance_daily_report。这七步中第 5 步的 SQL 是唯一可能失败的环节如网络抖动导致连接中断此时第 6、7 步不会执行而第 1-4 步因无持久化操作可安全丢弃。这种设计让系统具备天然的“最终一致性”比强一致性更适配考勤场景。3. 核心模块实现从请假审批状态机到考勤异常规则引擎3.1 请假审批状态机用数据库字段驱动流程而非硬编码 if-else很多同学把请假流程写成if (status.equals(PENDING)) { if (approve) updateStatus(APPROVED); else updateStatus(REJECTED); } else if (status.equals(APPROVED)) { // ... }这种写法在答辩时会被追问“如果领导A审批后领导B又点了一次通过按钮状态会不会错乱”本方案采用数据库字段 状态迁移表双保险leave_apply表增加status字段ENUM:DRAFT,SUBMITTED,APPROVING,APPROVED,REJECTED,CANCELLED新增leave_status_transition规则表from_statusto_statusallowed_rolecondition_sqlDRAFTSUBMITTEDEMPLOYEE11SUBMITTEDAPPROVINGMANAGERdepartment_id ?APPROVINGAPPROVEDMANAGERapproval_count 2审批操作统一走LeaveApplyService.transitionStatus(Long applyId, String toStatus)方法Transactional public void transitionStatus(Long applyId, String toStatus) { LeaveApply current leaveApplyMapper.selectById(applyId); // 1. 校验当前状态是否允许迁移到目标状态 StatusTransitionRule rule transitionMapper.selectByFromAndTo( current.getStatus(), toStatus); if (rule null) { throw new BusinessException(非法状态迁移 current.getStatus() → toStatus); } // 2. 校验操作人角色是否匹配 if (!rule.getAllowedRole().equals(getCurrentRole())) { throw new BusinessException(权限不足仅 rule.getAllowedRole() 可操作); } // 3. 执行条件 SQL如审批人数校验 if (!executeConditionSql(rule.getConditionSql(), applyId)) { throw new BusinessException(状态迁移条件不满足); } // 4. 更新状态乐观锁防止并发 int updated leaveApplyMapper.updateStatus(applyId, current.getStatus(), toStatus); if (updated 0) { throw new BusinessException(状态已被其他操作修改请刷新重试); } }这样设计的好处是流程变更无需改 Java 代码只需在后台管理界面维护leave_status_transition表且每次状态变更都有完整审计日志leave_apply_audit表记录谁、何时、从何状态变为何状态。3.2 考勤异常规则引擎用 Groovy 脚本实现可热更新的业务规则考勤异常判定如“迟到30分钟以上”、“连续3天未打卡”是业务方最常调整的部分。若写死在 Java 里每次改规则都要发版。本方案引入 Groovy 脚本引擎在resources/scripts/attendance-rules/下存放脚本文件如late-rule.groovy// late-rule.groovy def execute(MapString, Object context) { def checkInTime context.checkInTime as LocalDateTime def workStartTime context.workStartTime as LocalDateTime def lateThreshold context.lateThreshold as Integer // 单位分钟 def lateMinutes ChronoUnit.MINUTES.between(workStartTime, checkInTime) if (lateMinutes lateThreshold) { return [ type: LATE, description: 迟到 ${lateMinutes} 分钟, penaltyPoints: lateMinutes / 10 ] } return null }后端通过GroovyShell加载并执行Service public class AttendanceRuleEngine { private final ScriptEngineManager manager new ScriptEngineManager(); public RuleResult execute(String scriptName, MapString, Object context) { ScriptEngine engine manager.getEngineByName(groovy); try { // 从数据库或本地文件加载脚本内容 String scriptContent scriptLoader.load(scriptName); Invocable invocable (Invocable) engine.eval(scriptContent); return (RuleResult) invocable.invokeFunction(execute, context); } catch (Exception e) { log.error(执行规则脚本失败{}, scriptName, e); return null; } } }规则启用开关存于数据库attendance_rule_config表字段is_enabled控制是否加载该脚本。注意Groovy 脚本禁止使用System.exit()、new File()、反射调用私有方法等危险操作。上线前需经静态扫描用groovy-sandbox库隔离。3.3 移动端适配关键微信小程序扫码签到的 Token 续期策略开题报告里常提“支持微信小程序”但很少说明如何解决小程序 session 过期导致的重复登录问题。本方案采用“双 Token”机制Access TokenJWT有效期 2h携带employeeId、role、jti唯一标识Refresh Token随机字符串存于 Redis有效期 7 天Key 为refresh:${jti}Value 为对应 Access Token 的jti。小程序端逻辑每次 API 请求前检查 Access Token 是否将在 10 分钟内过期若即将过期调用/auth/refresh接口传入当前 Refresh Token后端校验 Refresh Token 有效性若有效则① 作废旧 Access Token将jti加入 Redis 黑名单② 签发新 Access Token 和新 Refresh Token③ 返回新 Token 对。关键代码Refresh 接口PostMapping(/refresh) public ResultMapString, String refresh(RequestBody RefreshRequest request) { String jti redisTemplate.opsForValue().get(refresh: request.getRefreshToken()); if (jti null) { throw new BusinessException(Refresh Token 已失效); } // 检查旧 jti 是否在黑名单 if (redisTemplate.hasKey(blacklist: jti)) { throw new BusinessException(Access Token 已被撤销); } // 生成新 Token String newJti UUID.randomUUID().toString(); String newAccessToken Jwts.builder() .setSubject(employee: employeeId) .claim(role, role) .setJti(newJti) .setExpiration(new Date(System.currentTimeMillis() 2 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); // 更新 Redis redisTemplate.delete(refresh: request.getRefreshToken()); redisTemplate.opsForValue().set(refresh: newJti, newJti, 7, TimeUnit.DAYS); return Result.success(Map.of(accessToken, newAccessToken, refreshToken, newJti)); }此设计确保用户在小程序内连续使用 7 天无需重新扫码登录同时保障安全性——即使 Access Token 泄露攻击者也无法获取 Refresh Token因其不参与网络传输仅存于 Redis。4. 关键避坑指南开发与答辩中最容易翻车的五个致命点4.1 翻车点一MySQL 时间字段用datetime还是timestamp选错直接导致跨时区统计错误现象系统部署到阿里云华东1区测试时一切正常但客户在新疆使用时考勤日报显示“打卡时间为次日凌晨”原因datetime类型存储的是字面值如2025-04-05 09:00:00不带时区信息而timestamp存储的是 UTC 时间戳读取时会根据 MySQL 服务器时区自动转换。当服务器时区设为Asia/Shanghai而小程序前端传入的时间是Asia/UrumqiUTC6时datetime会原样存储导致时间错位解决所有业务时间字段统一用datetime但强制约定所有时间均以Asia/Shanghai时区为准。后端接收前端时间字符串时先解析为LocalDateTime再通过ZonedDateTime.of(localDateTime, ZoneId.of(Asia/Shanghai))转为带时区时间最后提取Instant存入数据库。前端展示时也统一按Asia/Shanghai渲染。在application.yml中显式配置spring: jackson: time-zone: Asia/Shanghai date-format: yyyy-MM-dd HH:mm:ss4.2 翻车点二Vue 路由守卫里调用router.push()后页面白屏控制台无报错现象用户登录后beforeEach守卫中判断权限跳转到/dashboard但页面空白Network 面板显示dashboard页面 JS 文件 404原因Vue Router 4 的createRouter默认使用history模式但 Nginx 未配置try_files导致刷新/dashboard时 Nginx 直接返回 404而非回退到index.html解决Nginx 配置必须包含location / { try_files $uri $uri/ /index.html; }同时Vue 项目vue.config.js中配置publicPath为相对路径module.exports { publicPath: ./, // 禁止用 / 或 https://xxx.com outputDir: dist }否则打包后资源路径错误CSS/JS 加载失败。4.3 翻车点三MyBatis 的SelectProvider动态 SQL 中AND关键字拼接错误导致 SQL 语法错误现象查询请假列表时当status参数为空SQL 变成WHERE AND create_time ?直接报错原因手写SelectProvider时用StringBuilder拼接 SQL未处理WHERE后第一个条件前的AND解决永远使用 MyBatis 的where标签而非手拼select idselectLeaveList resultTypeLeaveVO SELECT * FROM leave_apply where if teststatus ! null and status ! AND status #{status} /if if teststartDate ! null AND apply_time #{startDate} /if /where ORDER BY apply_time DESC /selectwhere标签会自动处理WHERE关键字和首尾AND的清理。4.4 翻车点四JWT Token 存 localStorage 导致 XSS 攻击风险但存在即合理现象导师质疑“Token 存 localStorage 不安全”学生答“大家都这么存”原因localStorage确实可被 XSS 脚本读取但本方案面向内部管理系统且已实施 CSPContent Security Policy头限制脚本来源XSS 概率极低更重要的是考勤系统无金融级敏感操作如转账、修改密码Token 泄露最多导致他人代打卡风险可控解决不强行上HttpOnly Cookie会增加跨域调试成本而是① 前端所有localStorage.setItem(token, ...)操作前先调用sanitizeInput()过滤特殊字符② 后端 JWT 签发时设置短有效期2h并强制绑定设备指纹见 2.3 节③ 在application.yml中开启spring.session.store-typenone禁用 Spring Session避免 Cookie 冲突。4.5 翻车点五Quartz 定时任务在集群部署时重复执行凌晨日报生成两份现象系统部署到两台服务器每天 00:05 都生成一份日报数据库出现两条相同日期的记录原因Quartz 默认使用 RAMJobStore各节点独立调度解决必须切换为 JDBCJobStore并共享同一数据库。在quartz.properties中配置org.quartz.jobStore.class org.quartz.impl.jdbcjobstore.JobStoreTX org.quartz.jobStore.driverDelegateClass org.quartz.impl.jdbcjobstore.StdJDBCDelegate org.quartz.jobStore.dataSource myDS org.quartz.jobStore.tablePrefix QRTZ_ org.quartz.jobStore.isClustered true org.quartz.jobStore.clusterCheckinInterval 20000并在数据库中执行 Quartz 官方提供的tables_mysql_innodb.sql脚本创建 11 张表。集群节点通过QRTZ_LOCKS表争抢TRIGGER_ACCESS锁确保同一时刻仅一个节点执行任务。5. 数据库设计与性能压测从 ER 图到慢 SQL 优化实战5.1 核心表 ER 图与字段级设计说明本系统共 12 张表其中 5 张为核心业务表。ER 图省略但关键表结构必须满足以下约束表名字段名类型约束说明employeeidBIGINT PKAUTO_INCREMENT主键禁止用 UUID影响索引效率dept_idBIGINTNOT NULL, INDEX部门外键必须建索引entry_dateDATENOT NULL入职日期用于计算工龄attendance_recordidBIGINT PKAUTO_INCREMENT—employee_idBIGINTNOT NULL, INDEX—dateDATENOT NULL, INDEX联合索引(employee_id, date)必须存在支撑按人查历史、按日查全员check_in_timeDATETIMENULL允许为空未打卡statusTINYINTNOT NULL, DEFAULT 00未打卡1已打卡2请假3出差…leave_applyidBIGINT PKAUTO_INCREMENT—employee_idBIGINTNOT NULL, INDEX—start_dateDATENOT NULL请假开始日期end_dateDATENOT NULL请假结束日期statusVARCHAR(20)NOT NULL, INDEX状态枚举建索引加速查询attendance_daily_reportidBIGINT PKAUTO_INCREMENT—dateDATENOT NULL, UNIQUE唯一约束防止重复生成total_employeesINTNOT NULL应到人数checked_in_countINTNOT NULL实到人数late_countINTNOT NULL迟到人数提示attendance_record表预计日增 10 万条按 1 万人规模必须在date字段上建分区按月 RANGE 分区否则单表超千万行后SELECT COUNT(*)会严重拖慢日报生成。5.2 慢 SQL 优化三板斧执行计划、索引覆盖、读写分离针对开题报告中“考勤记录查询慢”的痛点本方案提供可落地的优化路径第一板斧用EXPLAIN定位瓶颈当查询SELECT * FROM attendance_record WHERE employee_id 1001 AND date BETWEEN 2025-04-01 AND 2025-04-30耗时 500ms执行EXPLAIN发现typeALL全表扫描EXPLAIN SELECT * FROM attendance_record WHERE employee_id 1001 AND date BETWEEN 2025-04-01 AND 2025-04-30;第二板斧建立覆盖索引原索引INDEX(employee_id)无法高效过滤date范围需创建联合索引ALTER TABLE attendance_record ADD INDEX idx_emp_date (employee_id, date);再次EXPLAINtyperangekeyidx_emp_date耗时降至 20ms。第三板斧读写分离应对高并发查询日报生成任务SELECT COUNT(*) FROM attendance_record WHERE date 2025-04-05与实时打卡INSERT INTO attendance_record ...争抢主库。方案主库Master只处理INSERT/UPDATE/DELETE从库Slave挂载 1 台只读实例所有报表类SELECT查询强制路由至此SpringBoot 中通过AbstractRoutingDataSource实现动态数据源切换Transactional注解的方法走主库ReadOnly自定义注解的方法走从库。5.3 压测方案与达标指标用 JMeter 模拟 500 并发打卡毕业设计验收必须提供压测报告。本方案设定硬性指标场景并发数请求路径P95 响应时间错误率数据库 CPU员工打卡500POST/api/v1/checkin≤ 800ms 0.1% 70%请假列表200GET/api/v1/leaves?page1size20≤ 300ms0% 50%日报生成1POST/api/v1/reports/daily≤ 15s0% 85%压测步骤使用 JMeter 创建线程组500 线程Ramp-up Period60sHTTP 请求中添加Authorization: Bearer ${token}头token 从 CSV 文件读取预生成 1000 个添加“聚合报告”监听器导出summary.csv数据库监控用SHOW PROCESSLISTpt-query-digest分析慢日志。若未达标按顺序排查① 检查 Redis 连接池是否耗尽max-active200② 查看 MySQLinnodb_buffer_pool_size是否足够建议设为物理内存 70%③ 检查attendance_record表是否已分区。6. 答辩与验收从开题报告到可演示系统的五步通关法6.1 开题报告答辩前必做的三件事很多同学把开题当成“写完交差”结果答辩时被问懵。我带的学生答辩前必须完成以下三件事缺一不可画出一张真实的部署拓扑图不是画“前端 ←→ 后端 ←→ 数据库”而是标出具体组件前端Nginx反向代理 Vue 打包后的dist目录 HTTPS 证书用 Lets Encrypt 免费签发后端SpringBoot Jar 包java -jar -Xms512m -Xmx1024m Actuator 端点/actuator/health,/actuator/metrics数据库MySQL 8.0主从复制 Redis 7.0哨兵模式监控Prometheus抓取 Actuator 指标 Grafana展示 QPS、JVM 内存、MySQL 连接数。这张图要能回答“如果 Nginx 挂了怎么办”“Redis 哨兵怎么选举”——不是背概念是讲清你部署时的真实选择。准备一份 3 分钟可演示的最小可行流程MVP第 1 分钟打开小程序扫码登录展示微信授权流程第 2 分钟点击“打卡”弹出定位确认框点击“确定”后显示“打卡成功”后端日志打印CheckInSuccessEvent第 3 分钟登录后台管理页进入“考勤记录”筛选今日看到刚打卡的记录数据库SELECT语句截图。这个 MVP 不需要所有功能但必须端到端打通证明你不是纸上谈兵。整理一份“已知缺陷与应对方案”清单缺陷描述影响范围短期方案长期规划微信小程序暂不支持蓝牙打卡仅影响部分考勤机场景文档注明“需配合硬件厂商 SDK”预留bluetooth-checkin接口待硬件对接报表导出 Excel 大文件卡顿导出 10 万行时前端假死改为后台生成邮件发送下载链接引入 Apache POI SXSSF 流式写入导师最欣赏直面问题的态度。与其说“没有缺陷”不如坦诚“这里我们做了取舍”。6.2 论文撰写中的三个隐藏得分点毕业论文不是技术文档而是工程能力的叙事。我在评审时会重点看这三个地方需求分析章节的“约束条件”表格不要只写“系统需支持 1000 用户”要写约束类型具体指标验证方式性能单次打卡请求 P95 ≤ 800msJMeter 压测报告截图安全Token 有效期 ≤ 2h且绑定设备指纹JWT 解析截图 RedisGET refresh:*结果兼容支持微信小程序基础库 2.20.0小程序开发者工具真机调试日志这种表格让需求可测量、可验证。系统测试章节的“边界值用例”不能只写“测试了正常打卡”要列用例 IDTC-ATT-003输入{ latitude: 40.7128, longitude: -74.0060, time: 2025-04-05T08:59:59 }精确到秒的临界值预期{code:200,message:打卡成功}实际同预期截图Postman 请求/响应截图 MySQLSELECT结果边界值测试证明你懂软件工程。总结章节的“技术选型对比表”不要写“Vue 比 React 好”要写评估维度Vue 3 Composition APIReact 18 Hooks本项目选择理由学习成本低指令式语法直观中JSX Hooks 概念多团队成员无前端经验需快速上手生态成熟度Element Plus 组件库完善Ant Design Vue 更丰富Element Plus 对表单校验支持更好构建速度Vite 启动 1sVite 同样快无差异不作为决策因素这种对比体现决策理性。6.3 答辩现场的“三问三答”话术模板答辩时老师常问三类问题我教学生用固定话术回应既专业又不露怯Q1为什么用 SpringBoot 而不用 Spring Cloud→ A“本系统定位为单体应用核心诉求是快速交付、降低运维复杂度。Spring Cloud 带来的服务发现、熔断等能力在考勤场景中属于过度设计——我们没有跨服务调用所有业务都在一个 JVM 内完成。若未来扩展为多校区独立部署再考虑按地域拆分为 Spring Cloud 微服务。”Q2数据库没做分库分表万一大数据量怎么办→ A“当前设计已预留扩展性①attendance_record表按date分区支撑千万级数据② 所有查询强制走联合索引避免全表扫描③ 若数据量持续增长我们会在employee_id上做哈希分库分库键就是员工 ID因为考勤查询 90% 是按人查。这是我们在‘未来工作’章节明确写的演进路径。”Q3你这个系统和市面上的钉钉考勤有什么区别→ A“钉钉是通用平台我们是垂直场景解决方案。区别有三点①定制化规则钉钉的迟到规则固定为‘上班时间后 X 分钟’而我们的规则引擎支持 Groovy 脚本可写‘周末加班后次日可晚到 1 小时’②数据主权所有数据存于客户私有服务器符合等保要求③集成成本我们提供标准 RESTful API3 天内可对接客户 HR 系统而钉钉需走官方 ISV 流程。”从那以后我每次指导开题都强制学生先画出部署拓扑图、跑通 MVP、填好本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
