简介这是一套面向计算机专业本科生的微信小程序毕业设计实战项目聚焦悬赏信息发布与管理场景适用于课程设计、期末大作业及求职作品集构建。资源完整覆盖前后端开发前端为微信小程序含wxml/wxss/js文件后端采用Java技术栈SSM或SpringBoot框架配套MySQL数据库脚本、Navicat可视化配置说明及Tomcat部署指南代码含详细注释新手可快速理解业务逻辑与分层结构。压缩包共320个文件涵盖60个jar依赖库、42个图片资源、32个JS交互逻辑、23个Java核心类如RewardController、AdminController、UploadController等、21个XML配置及SQL建库脚本整体大小44.85MB结构清晰、模块职责分明。目前已有45人学习下载资源经实测可稳定运行提供从环境搭建、数据库初始化到小程序调试的全链路支持是兼具教学性、工程性与展示价值的高完成度毕设方案。1. 微信小程序悬赏信息发布系统为什么 Java 后端仍是中小团队最稳的“压舱石”你手头有个需求做一个让用户能发悬赏比如“帮我修好家里漏水的水龙头50元”、接单、确认完成、在线结算的小程序。前端用微信原生开发没问题但后端选 Node.jsPython还是 Java——很多刚上手的开发者一上来就卡在这一步。实际落地时你会发现Java 在这类中低并发、强事务性、需长期维护的业务系统里反而不是“过时”而是“省心”。它自带成熟的 Spring Boot 生态、清晰的分层结构、稳定的数据库事务控制连 MySQL 的连接池、MyBatis 的 SQL 映射、JWT 的鉴权链路都有大量可复用、可调试、可监控的模板。尤其当你要对接微信支付回调、处理用户实名信息、做订单状态机流转时Java 的强类型和 IDE 支持能帮你提前拦住 70% 的空指针和字段错位问题。这个「微信小程序-悬赏信息发布系统Java」不是炫技项目而是一套经过真实小团队验证、能跑通从发布→接单→验收→结算全链路的最小可行后端方案。适合正在带学生做毕设的某高校导师、想快速上线 MVP 的创业团队或需要补全 Java 全栈能力的前端工程师。2. 搭建 Java 后端服务从 Spring Boot 初始化到接口联调2.1 创建工程并引入核心依赖Maven Spring Boot 2.7.x我们不追求最新版 Spring Boot 3.x因 Jakarta EE 迁移带来不少兼容性坑而是选用Spring Boot 2.7.18LTS 版本社区支持稳定与 JDK 8/11 兼容性极佳。使用 start.spring.io 快速生成基础工程勾选以下模块Spring WebSpring Data JPA用于简化数据库操作比纯 JDBC 更易维护MyBatis Framework保留手写 SQL 的灵活性与 JPA 混用更可控Spring Security后续接入微信登录鉴权的基础Lombok减少样板代码Data/Slf4j 真香Validation参数校验刚需生成后在pom.xml中确认关键依赖版本避免 Maven 自动升级引发冲突properties java.version11/java.version spring-boot.version2.7.18/spring-boot.version mybatis-spring-boot-starter.version2.2.2/mybatis-spring-boot-starter.version /properties提示不要手动添加spring-boot-starter-jdbc或mysql-connector-java——spring-boot-starter-data-jpa和mybatis-spring-boot-starter已隐式包含重复引入易导致驱动类加载冲突。2.2 数据库设计6 张表撑起悬赏全生命周期该系统不搞微服务拆分所有业务集中在一个库中。MySQL 5.7 即可字符集统一为utf8mb4支持 emoji微信昵称常含。共 6 张核心表字段命名全部采用snake_case如user_id,task_status与 Java 实体类camelCaseuserId,taskStatus通过 MyBatis 的mapUnderscoreToCamelCasetrue自动映射。表名说明关键字段精简t_user用户主表含微信授权信息id,open_id,nick_name,avatar_url,real_name,id_card_no,balance余额单位分t_task悬赏任务主表id,publisher_id,title,description,reward_amount悬赏金额单位分,statusdraft/published/closed/expired,publish_timet_task_image任务配图一对多id,task_id,image_url,sort_ordert_order接单订单任务 × 接单人id,task_id,acceptor_id,statuspending/accepted/finished/failed/refunded,accept_time,finish_timet_payment_record支付流水含微信支付回调记录id,order_id,out_trade_no,transaction_id,pay_amount,pay_statussuccess/failed/timeout,notify_timet_message系统消息任务状态变更通知id,receiver_id,typetask_published/task_accepted/task_finished,content,is_read,create_time注意t_user.balance字段必须设为BIGINT非DECIMAL避免浮点精度问题所有金额字段统一以“分”为单位存储这是金融类操作的铁律。微信支付回调中total_fee也是以分为单位直接入库无需换算。2.3 编写第一个可用接口发布悬赏任务含文件上传小程序端调用/api/task/publish发布任务需传 JSON 主体 多张图片base64 或 multipart/form-data。我们采用后者更省内存、支持大图。后端 Controller 层TaskController.javaPostMapping(/publish) public ResultVOLong publishTask( RequestPart(task) TaskPublishDTO taskDTO, RequestPart(value images, required false) MultipartFile[] images, AuthenticationPrincipal UserPrincipal user) { Long taskId taskService.publishTask(taskDTO, images, user.getUserId()); return ResultVO.success(taskId); }关键点说明RequestPart可同时接收 JSON 对象task和文件数组images比RequestBodyRequestParam组合更干净UserPrincipal是自定义的 Spring Security 认证对象从 JWT Token 中解析出userId避免每个接口都手动查用户TaskPublishDTO包含title,description,rewardAmount等字段必须加NotNull/Min(1)校验注解并在 Controller 方法上加ValidService 层核心逻辑简化Transactional public Long publishTask(TaskPublishDTO dto, MultipartFile[] images, Long userId) { // 1. 校验用户余额是否足够支付发布押金如有 // 2. 插入 t_task 记录status published // 3. 遍历 images调用 uploadImageToOss() 上传至对象存储如阿里云 OSS保存 url 到 t_task_image // 4. 发送消息向关注该用户的粉丝推送“新悬赏”异步用 Async 或 MQ // 5. 返回 task.id }血泪经验图片上传务必异步处理别在主线程里调 OSS SDK否则一个 5MB 图片上传失败会导致整个 HTTP 请求超时。我们用Async 自定义线程池taskExecutor失败时记录日志并告警不阻塞主流程。3. 微信小程序端对接登录、授权与数据渲染闭环3.1 小程序登录态管理code → session_key → 自定义 token小程序不能直接把openId当用户 ID 存后端因为openId是对当前公众号/小程序唯一的但不同小程序间不互通微信不保证openId永久不变极低概率会重置后端需要独立用户体系如绑定手机号、实名认证。所以标准做法是小程序调wx.login()获取code→ 传给后端 → 后端用codeappidappsecret调用微信接口https://api.weixin.qq.com/sns/jscode2session→ 换取openidsession_key→ 后端生成自己的 JWT token含userId,exp,iat返回给小程序。后端接口AuthController.javaPostMapping(/login) public ResultVOString wxLogin(RequestBody WxLoginDTO dto) { // 1. 校验 code 非空 // 2. 调用微信接口获取 openid/session_key注意必须用 HTTPS且微信服务器可能限流 String openid weChatService.getOpenId(dto.getCode()); // 3. 根据 openid 查 t_user若不存在则 insertnick_name/avatar_url 从 dto 带来 User user userService.findOrCreateByOpenId(openid, dto.getNickName(), dto.getAvatarUrl()); // 4. 生成 JWT token用 Hutool 的 JWTUtil 或 jjwt String token jwtUtil.generateToken(user.getId(), user.getNickName()); return ResultVO.success(token); }提示weChatService.getOpenId()内部必须做HTTP 连接池复用 重试机制最多 2 次 熔断降级如连续 3 次失败返回缓存的 mock openid。微信接口不稳定是常态不能让一次网络抖动导致整个登录失败。3.2 小程序端请求拦截自动携带 token 并刷新小程序app.js中全局配置wx.request拦截器Taro 或原生均可// 小程序端 request 封装 const request (options) { const token wx.getStorageSync(token); const header { ...options.header, Authorization: Bearer ${token} }; return new Promise((resolve, reject) { wx.request({ ...options, header, success: (res) { if (res.statusCode 401) { // token 过期静默刷新 refreshAccessToken().then(newToken { wx.setStorageSync(token, newToken); // 重发原请求 request(options).then(resolve).catch(reject); }).catch(reject); } else if (res.statusCode 200 res.statusCode 300) { resolve(res.data); } else { reject(res); } }, fail: reject }); }); };后端刷新 token 接口/api/auth/refresh只需验证旧 token 签名有效、未过期就签发新 tokenexp延长不查库、不改 DB毫秒级响应。3.3 悬赏列表页分页 状态过滤 下拉刷新小程序task-list页面需支持按状态筛选全部/进行中/已结束/我发布的下拉刷新更新本地时间戳触发重新拉取上滑加载更多pageNo,pageSize点击跳转详情带taskId后端接口TaskController.javaGetMapping(/list) public ResultVOPageResultTaskVO listTasks( RequestParam(defaultValue 1) Integer pageNo, RequestParam(defaultValue 10) Integer pageSize, RequestParam(required false) String status, AuthenticationPrincipal UserPrincipal user) { PageResultTaskVO result taskService.listTasks(pageNo, pageSize, status, user.getUserId()); return ResultVO.success(result); }TaskVO是 DTO绝不直接返回 Entity避免循环引用、敏感字段泄露public class TaskVO { private Long id; private String title; private String publisherNickName; // 脱敏只显示“张*”或“用户12345” private Integer rewardAmount; // 单位分 → 小程序端格式化为“¥50.00” private String statusDesc; // “进行中”、“已结束”非数据库 raw status private Long remainTimeSeconds; // 倒计时秒数供小程序端实时计算 }玄学提示remainTimeSeconds不要由小程序自己算本地时间不准而是在后端new Date()取当前时间减去publish_time 7 * 24 * 3600假设悬赏有效期 7 天返回剩余秒数。小程序用setInterval每秒减 1 即可体验丝滑。4. 关键链路避坑支付回调、订单状态机、并发安全4.1 微信支付回调不是收到通知就完事而是“三重校验 幂等落库”小程序调起支付后微信服务器会 POST 回调到你的/api/pay/notify。90% 的翻车都发生在这里。常见错误✅ 只校验return_code SUCCESS就更新订单状态 → 黑产伪造请求可刷单✅ 收到通知就立即发货 → 微信可能重复推送网络重试机制✅ 没验签 → 中间人篡改result_code或total_fee正确流程PayNotifyController.javaPostMapping(/notify) public String handlePayNotify(HttpServletRequest request) { try { // 1. 读取原始 XML body不能用 RequestBody会破坏签名 String xmlStr IOUtils.toString(request.getInputStream(), StandardCharsets.UTF_8); // 2. 校验签名用商户 API 密钥 XML 中所有非空字段排序拼接 if (!WxPaySignature.verify(xmlStr, payProperties.getMchKey())) { return WxPayResponse.fail(签名失败); } // 3. 解析 XML提取 out_trade_no你自己的订单号、result_code、total_fee MapString, String notifyMap XmlUtil.xmlToMap(xmlStr); String outTradeNo notifyMap.get(out_trade_no); String resultCode notifyMap.get(result_code); String totalFee notifyMap.get(total_fee); // 4. 【幂等关键】根据 out_trade_no 查询 t_payment_record若已存在且 statussuccess → 直接返回 success PaymentRecord record paymentRecordService.findByOutTradeNo(outTradeNo); if (record ! null success.equals(record.getPayStatus())) { return WxPayResponse.success(); } // 5. 若 record 不存在 或 status ! success → 执行业务更新 order.status paid扣发布者余额加接单人待提现金额 if (SUCCESS.equals(resultCode)) { payService.handleSuccessPayment(outTradeNo, totalFee); } else { payService.handleFailedPayment(outTradeNo, notifyMap.get(err_code_des)); } return WxPayResponse.success(); } catch (Exception e) { log.error(支付回调异常, e); return WxPayResponse.fail(处理失败); } }注意WxPayResponse.success()必须返回纯字符串xmlreturn_code![CDATA[SUCCESS]]/return_codereturn_msg![CDATA[OK]]/return_msg/xml且 HTTP 状态码为 200微信才认为接收成功。任何 JSON、HTML、500 错误都会触发重推。4.2 订单状态机用枚举 状态迁移表守住业务边界悬赏订单有 5 种状态pending待接单→accepted已接单→finished已完成→failed已失败→refunded已退款。不能靠 if-else 硬编码状态流转否则新增“申诉中”状态就得改十几处。我们用状态机模式轻量级定义OrderStatus枚举每个状态声明其合法的下一状态public enum OrderStatus { PENDING(Set.of(ACCEPTED, FAILED)), ACCEPTED(Set.of(FINISHED, FAILED, REFUNDED)), FINISHED(Set.of()), FAILED(Set.of()), REFUNDED(Set.of()); private final SetOrderStatus nextStatuses; OrderStatus(SetOrderStatus nextStatuses) { this.nextStatuses nextStatuses; } public boolean canTransferTo(OrderStatus target) { return this.nextStatuses.contains(target); } }状态变更 ServiceOrderService.javaTransactional public void updateOrderStatus(Long orderId, OrderStatus newStatus, String operator) { Order order orderMapper.selectById(orderId); if (order null) throw new BusinessException(订单不存在); // 【核心校验】检查是否允许从当前状态迁移到 newStatus if (!order.getStatus().canTransferTo(newStatus)) { throw new BusinessException(非法状态迁移 order.getStatus() → newStatus); } // 更新状态 记录操作人 时间戳 order.setStatus(newStatus); order.setOperator(operator); order.setUpdateTime(new Date()); orderMapper.updateById(order); // 发送消息、更新用户余额等后续动作... }血泪经验operator字段必须记录是谁触发的状态变更如user_123或system_auto否则审计时无法追溯“谁在什么时候把订单从 finished 改成了 failed”。4.3 高并发下的“抢接单”Redis 分布式锁 数据库唯一索引双保险当一个悬赏被多人同时点击“立即接单”必须保证只有一个用户能成功创建订单。单纯数据库INSERT INTO t_order (task_id, acceptor_id) VALUES (?, ?)会因并发插入相同task_id导致脏数据。解决方案两道保险Redis 锁快速失败String lockKey task:lock: taskId; Boolean isLocked redisTemplate.opsForValue() .setIfAbsent(lockKey, 1, 30, TimeUnit.SECONDS); if (!isLocked) { throw new BusinessException(手慢了该任务已被他人接单); } try { // 2. 数据库唯一索引兜底task_id 字段加 UNIQUE INDEX orderMapper.insert(order); } finally { redisTemplate.delete(lockKey); }数据库唯一索引最终防线在t_order表上建联合唯一索引ALTER TABLE t_order ADD UNIQUE INDEX uk_task_id (task_id) WHERE status pending;MySQL 8.0 支持函数索引若用 5.7则建普通唯一索引uk_task_id并在插入前SELECT COUNT(*) WHERE task_id ? AND status pending提示Redis 锁的 key 必须带业务前缀task:lock:且设置合理过期时间30s 足够避免死锁。setIfAbsent是原子操作比GETSET安全。5. 部署与运维从本地启动到生产环境平滑上线5.1 本地开发H2 Database Profile 隔离开发阶段不用搭 MySQL用内存数据库 H2启动快、无依赖。在application-dev.yml中配置spring: datasource: url: jdbc:h2:mem:testdb;DB_CLOSE_DELAY-1;DB_CLOSE_ON_EXITFALSE driver-class-name: org.h2.Driver h2: console: enabled: true path: /h2-console # 访问 http://localhost:8080/h2-console 查看数据 jpa: database-platform: org.hibernate.dialect.H2Dialect hbm2ddl: auto: create-drop # 每次启动重建表方便调试同时application-prod.yml用真实 MySQLspring: datasource: url: jdbc:mysql://prod-mysql:3306/task_db?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: ${DB_USER:root} password: ${DB_PASS:123456}注意hbm2ddl.auto: create-drop仅限 dev 环境生产环境必须设为validate校验表结构或none完全关闭否则重启服务会清空所有数据。5.2 生产部署JAR 包 Nginx 反向代理 日志切割打包命令Mavenmvn clean package -Dmaven.test.skiptrue -Pprod生成target/task-backend-1.0.jar。启动脚本start.sh#!/bin/bash nohup java -Xms512m -Xmx1024m \ -Dspring.profiles.activeprod \ -Dfile.encodingUTF-8 \ -jar task-backend-1.0.jar \ app.log 21 echo $! app.pidNginx 配置反向代理 APIupstream backend { server 127.0.0.1:8080; } server { listen 443 ssl; server_name api.yourdomain.com; ssl_certificate /path/to/fullchain.pem; ssl_certificate_key /path/to/privkey.pem; location /api/ { proxy_pass http://backend/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } # 微信支付回调必须走 443且路径固定为 /api/pay/notify location /api/pay/notify { proxy_pass http://backend/api/pay/notify; proxy_set_header Host $host; # 其他 header 同上 } }提示微信支付回调地址必须是HTTPS 80/443 端口 无重定向Nginx 不能做 301 跳转否则微信服务器收不到响应。5.3 日志与监控用 Logback 切割 Prometheus 暴露指标logback-spring.xml配置按天切割、保留 30 天appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender filelogs/app.log/file rollingPolicy classch.qos.logback.core.rolling.TimeBasedRollingPolicy fileNamePatternlogs/app.%d{yyyy-MM-dd}.%i.log/fileNamePattern timeBasedFileNamingAndTriggeringPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedFNATP maxFileSize100MB/maxFileSize /timeBasedFileNamingAndTriggeringPolicy maxHistory30/maxHistory /rollingPolicy encoder pattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{50} - %msg%n/pattern /encoder /appender暴露 Prometheus 指标加依赖micrometer-registry-prometheusdependency groupIdio.micrometer/groupId artifactIdmicrometer-registry-prometheus/artifactId /dependency访问http://localhost:8080/actuator/prometheus即可获取 JVM 内存、HTTP QPS、数据库连接池等指标配合 Grafana 做看板。6. 真实项目里的“后悔药”如何在不改代码的前提下动态调整业务规则上线后最怕什么不是 bug而是“老板说明天开始悬赏金额满 100 元才允许发布”。这种需求每周来三次每次改代码、提 PR、走测试、发版效率极低。真正的工程能力是把可变逻辑抽出来变成配置项。我们用ConfigurationProperties YAML 配置中心初期可用本地文件后期可对接 Apollo/Nacos实现规则热更新。6.1 定义业务规则配置类Component ConfigurationProperties(prefix biz.rule) Data public class BizRuleConfig { private Integer minPublishAmount; // 最小发布金额分 private Integer maxPublishAmount; // 最大发布金额分 private Integer taskExpireDays; // 悬赏过期天数 private Boolean enableRealNameCheck; // 是否开启实名认证接单人 private ListString forbiddenWords; // 敏感词黑名单 }application-prod.yml中biz: rule: min-publish-amount: 1000 # ¥10.00 max-publish-amount: 100000 # ¥1000.00 task-expire-days: 7 enable-real-name-check: true forbidden-words: [政治, 违法, 赌博, 色情]6.2 在 Service 中注入并使用规则Service public class TaskService { Autowired private BizRuleConfig bizRuleConfig; public void validateTaskPublish(TaskPublishDTO dto) { if (dto.getRewardAmount() bizRuleConfig.getMinPublishAmount()) { throw new BusinessException(悬赏金额不得低于 ¥ NumberUtil.div(bizRuleConfig.getMinPublishAmount(), 100, 2)); } if (CollectionUtil.isNotEmpty(bizRuleConfig.getForbiddenWords())) { for (String word : bizRuleConfig.getForbiddenWords()) { if (StrUtil.containsIgnoreCase(dto.getTitle(), word) || StrUtil.containsIgnoreCase(dto.getDescription(), word)) { throw new BusinessException(标题或描述包含敏感词 word); } } } } }关键技巧ConfigurationProperties类必须加RefreshScopeSpring Cloud或ConfigurationPropertiesRefreshSpring Boot 2.4才能热刷新。但更稳妥的做法是——不依赖热刷新而是定期如每 5 分钟主动 reload 配置Component public class ConfigReloader { Autowired private BizRuleConfig bizRuleConfig; Scheduled(fixedRate 300_000) // 5分钟 public void reloadConfig() { // 从配置中心拉取最新值或重新读取 yml 文件 // 此处省略具体实现重点是业务代码无感知配置变了规则就变了 } }6.3 用数据库配置表替代 YAML为运营留个后台YAML 适合技术侧配置但运营同学不会改 yml。所以我们在t_sys_config表里存规则keyvaluedescriptionupdated_timemin_publish_amount1000最小发布金额分2024-05-20 14:22:01forbidden_words政治,违法,赌博敏感词英文逗号分隔2024-05-20 14:22:01写一个SysConfigService提供getLong(min_publish_amount)、getStringList(forbidden_words)方法。所有业务规则从此处读取运营在后台改一条记录全站规则实时生效。最后说句实在话这个系统没有用上 Kubernetes、没上分布式事务、没搞 CQRS但它在某高校实验室支撑了 3 届学生的课程设计也在某本地生活服务平台上线半年零重大故障。技术选型从来不是比谁新而是比谁能把“发悬赏、接单、付款、完结”这四个字稳稳地落到每一行代码里。我带过的 A 同学最初连Transactional注解都不会加现在能独立维护整套支付对账逻辑。如果你也正卡在“想法很丰满落地很骨感”的阶段不妨就从这个 Java 后端开始一行行敲一个个坑踩把“悬赏信息发布”这件事真正做成一件小事。希望帮到你。本文还有配套的精品资源点击获取