Spring Boot + 微信小程序：老年防诈科普交流平台开发实践

开头：

这两年社区里关于老年人遭遇电信诈骗的新闻越来越多，我家里老人就差点中过“冒充孙子出车祸要手术费”的招。事后我翻了不少反诈App和科普文章，发现一个尴尬的事实——这些内容做得再好，老人根本看不进去、用不来。字体太小、操作太复杂、信息太官方，加上老人独自在家时没人讨论、没人提醒，诈骗分子反倒天天嘘寒问暖。正好那段时间我在做Spring Boot服务端开发，也接触了不少微信小程序项目，就萌生了一个想法：用Spring Boot搭后端，微信小程序做前端，做一个专门给老年人用的防诈科普及交流平台。断断续续开发了几个月，目前核心功能全部跑通，这篇文章把我从需求分析到部署上线的完整思路、关键代码和踩过的坑都整理出来，给有类似需求的朋友做个参考。

1. 老年防诈平台到底在解决什么具体问题

1.1 现有防诈手段的盲区：不是没有内容，而是内容到不了老人手里

市面上的防诈产品大致分三类：公安机关的反诈App、银行的交易风险提醒、以及各种公众号里的科普文章。这些产品有一个共同点：预设用户是“会上网、看得懂、愿意主动学习”的人群。但老年群体的实际情况完全不同，很多老人用的是子女淘汰下来的旧手机，能熟练操作的就是微信里的语音和视频通话，让他们去装一个独立App并每天打开看，门槛实在太高。就算装上反诈App，来电预警确实有效，但老人对“什么是诈骗”本身缺乏判断力——对方让他下载某个会议软件、开启屏幕共享，他根本不知道这一步意味着什么。

这就是第一个要解决的问题：防诈科普的触达渠道必须建立在老人已经熟悉的工具上。微信是绝大多数老年人每天都会打开的软件，小程序天然存在微信生态里，不用额外安装、入口浅、分享方便，这比做一个独立App要务实得多。我的结论很直接：老年用户的产品，首要考虑的不是功能有多炫，而是“他愿不愿意每天打开”。

1.2 老年用户的三大典型特征决定了产品形态

我把老年用户的使用特征归纳为三点，这三点直接影响了后面所有的功能设计和技术选型。

第一，生理机能下降。视力普遍衰退，看小字很吃力；手指精细操作能力变弱，小按钮点不准；听力下降，视频内容没字幕就听不懂。这要求UI必须做到字号大、按钮大、留白足、层级浅。

第二，认知模式偏经验化。老年人接受新事物更喜欢“看到身边人用、听子女推荐”，对抽象概念信任度低。他们更愿意相信“隔壁老张说这个有用”，而不是平台自己说自己权威。所以平台必须有社区属性，让老人之间能互相分享、互相提醒，而不是单向接收官方内容。

第三，情感需求强烈。不少老人被诈骗分子“攻心”，恰恰是因为对方天天陪他们聊天、嘘寒问暖，填补了子女不在身边的孤独感。防诈平台如果只是冷冰冰的功能列表，很难和这种情感攻势抗衡。社区交流、语音互动、友善的客服响应，这些看似和“防诈”无关的功能，其实是平台留住用户的核心。

1.3 “科普+交流”双重定位：内容要权威，社区要有温度

基于上述分析，平台定位为“科普+交流”双引擎。科普端解决“知道”的问题，由管理员持续发布适合老年阅读的防诈内容，包括骗局拆解、真实案例改编、电话接听指南等；交流端解决“信服”和“巩固”的问题，老人可以在社区里发帖、评论、分享自己的经历，也可以直接向平台提问“我接到的这个电话是不是骗子”，平台运营人员和志愿者会在后台给予解答。

这两个模块不是割裂的。科普文章页面底部会带“去社区聊聊”的入口，社区里讨论热度高的话题又会反哺内容选题。老人读了文章、在社区里得到回应、再把文章转发到家庭群，整个链路才算完成“知道—相信—传播”的闭环。

2. 技术选型逻辑：为什么是Spring Boot和微信小程序

2.1 后端框架的选型对比，为什么要锚定Spring Boot

后端可选的主流方案不少，我实际比较过Node.js的Express、Python的Django和Java的Spring Boot。最终选择Spring Boot，核心原因是生态成熟度和长期维护成本的平衡。

• 团队技术积累：国内Java开发者的基数大，Spring Boot作为事实上的企业级标准框架，遇到任何问题都能搜到大量解决方案，这对个人开发者和中小团队非常重要。我做这个项目不是写完就扔，后续还要持续迭代，团队维护的难度必须放在首位。
• 快速开发能力：Spring Boot的自动配置机制让我不用花大量时间写配置，只需要引入spring-boot-starter-web、spring-boot-starter-data-redis、MyBatis-Plus这几个核心依赖，一个可运行的服务端骨架很快就搭起来了。对于个人开发者来说，这种“开箱即用”的体感比框架本身的性能上限更重要。
• 部署运维生态：JAR包直接运行，或者打个Docker镜像扔到服务器上，都极其方便。Spring Boot Actuator还提供了现成的健康检查接口，接入运维监控非常省事。

版本上我强烈建议用Spring Boot 2.7.x。Spring Boot 3.x虽然已经发布很久，但它基于JDK 17，而且部分第三方中间件的自动配置类内部结构改了，一些公司还在用JDK 8甚至老版本CentOS，环境升级的代价需要评估。我一开始图新鲜用了Spring Boot 3.0，结果发现项目中用到的某个老版本OCR SDK不兼容jakarta命名空间，折腾了两天才换回2.7.x。如果是从零开始的新项目、团队也愿意升级JDK，那用3.x没问题；但如果要兼容老环境，或者像本项目这样要快速跑通业务逻辑，2.7.x是更稳妥的选择。

2.2 前端为什么选微信小程序，而不是H5或原生App

前端形态我纠结了很久，最终确定微信小程序，但不是“微信小程序就是好”，而是“在目标人群和使用场景下，微信小程序是综合成本最低的路径”。

先说原生App，劣势非常明显：老年人没有主动下载安装新App的习惯，即便装上了，图标混在一堆APP里很难找到。而且iOS和Android两套都要维护，对个人开发者的成本太高。这一条直接排除。

再说H5，开发确实快，但在微信内打开的体验不够原生——加载速度、页面切换流畅度、调用系统能力都受限。尤其是语音播报这种老年用户的高频功能，H5调用微信JSSDK的权限和稳定性都不如小程序原生能力。而且H5没有独立的入口，用户下次想访问还得翻聊天记录，留存率会很差。

微信小程序的优势在于：它寄生在微信这个老人最常用的App里。下拉微信首页就能找到小程序，点开即用，用完即走，没有安装负担。同时小程序提供了完整的能力矩阵——微信登录、订阅消息推送、同声传译插件（语音播报）、open-type能力，这些正好命中老年用户的核心需求。

前端框架我选了uni-app。一是因为它的Vue语法写起来顺手，二是因为保留了一稿多端编译的可能性，万一以后要出App版本，不用推倒重来。不过要提醒一句：uni-app开发微信小程序时，部分原生组件（如map、video）的兼容处理比较麻烦，做项目前建议先在开发者工具里跑一下官方模板，确认自己用到的组件没问题再大规模开工。

2.3 整体技术栈清单

这个组合最大的好处是“每个环节都有大量现成的坑和答案”。个人开发者的时间是最贵的，选生态成熟的技术栈，本质上是在用社区的集体经验给自己兜底。

3. 系统架构与核心数据模型设计

3.1 整体架构：三层结构，边界清晰

系统的物理架构不复杂，但边界必须划清楚。我按照“小程序端—服务端—基础设施”来切：

小程序端负责页面渲染和用户交互，只通过HTTP/HTTPS接口与服务端通信，不直接访问数据库。服务端是Spring Boot应用，内部按“Controller—Service—Mapper”三层组织，对外提供RESTful API。基础设施这一层包含MySQL（业务数据）、Redis（缓存）、对象存储（文章图片、社区图片），以及腾讯的位置服务（如果后续要做周边反诈活动地图）。

值得强调的是，我把对象存储单独拆出来而不是把图片存在服务器本地磁盘。原因很简单：小程序对包体积有2MB限制，虽然图片可以走网络加载，但如果把图片都放在服务端的Tomcat目录下，随着内容积累，磁盘占用和备份成本都会失控，而且用户上传的图片如果是Base64直接入库，那数据库很快就会成为灾难。用OSS/腾讯云COS这类对象存储，配合后端预签名URL实现直传，既能减轻服务器带宽压力，又能保证图片访问速度。

3.2 数据库设计中的核心表结构

数据库是这类平台的地基。我设计了八张核心表，这里挑几张最有代表性的拆开说。

用户表（t_user） 是最基础的。字段包括id、openid（微信唯一标识）、nickname、avatar、phone、role（普通用户/志愿者/管理员）、parent_user_id（绑定的子女账号ID）、status、create_time。这里有个容易被忽略的细节：openid必须加唯一索引。同一部手机用不同的微信登录，openid是唯一的，但你不能信任前端传来的userId，所有用户识别必须通过openid这个服务端可校验的字段。另外parent_user_id是我专门为“子女关怀”场景加的字段，后面会详细讲它的价值。

科普文章表（t_article） 的核心字段是title、summary、content（长文本）、category_id、cover_url、view_count、like_count、status（草稿/已发布/下架）、is_voice_available、source_url。设计时有个关键决策：正文用富文本存储而不是纯文本。老年人阅读需要有大字号和分段排版，富文本能保留格式。但富文本有安全性隐患——XSS攻击，这要求服务端必须做HTML标签白名单过滤，我在项目中直接用了Jsoup来做清洗，凡是script、iframe、onclick这些危险内容一律剔除。

社区帖子表（t_post）和评论表（t_comment） 相对常规，但有两个字段要想清楚。一个是status的取值，除了正常/删除之外，必须有“待审核”“审核不通过”两个状态，否则审核系统没法落地；另一个是冗余字段：t_post里冗余一个comment_count和like_count，虽然打破了严格范式，但能避免每次展示帖子列表都要COUNT一次评论表，性能提升非常明显。

举报记录表（t_report） 是为了社区治理设计的。字段包括report_type（垃圾广告/诈骗信息/人身攻击/其他）、target_type（帖子/评论/用户）、target_id、reporter_id、handle_status、handle_result。这里我的建议是：举报表不落最终处理结果，只落状态流转，具体的处理动作（比如封禁用户、删除帖子）通过服务异步执行，便于后续审计追踪。

3.3 核心API设计：接口先行，减少前后端扯皮

前后端并行开发时，接口文档就是合同。我用一个简单的表格把核心接口列出来，给后端开发一个明确的实现target：

这里有一条实际踩过的经验：所有返回结构必须统一。我定义了Result 类，包含code、message、data三个字段，错误时data为null。前后端统一用这个协议，后期排查问题会舒服很多。如果每个接口的返回结构都不一样，前端写起来会疯掉。

4. 功能模块实现：从登录到社区互动

4.1 微信登录：用code2Session换openid，而不是信任前端传参

小程序登录是最容易出问题的环节之一。很多新手直接在用户点击“微信一键登录”时，调用wx.getUserProfile去拿用户信息然后传给后端，这是错的。wx.getUserProfile拿到的只是用户的微信昵称和头像，并不能用于身份识别，而且这个接口现在已经调整了策略，部分新版本小程序里已经无法返回真实的昵称头像。

正确的登录链路是：

第一步，小程序端调用wx.login()获取临时code；
第二步，把code传给自己的后端接口，由后端调用微信服务器，组合appid+secret+code去换取openid和session_key。这个过程中appsecret必须保存在服务端，绝不能写在小程序代码里，否则任何人抓包都能拿到你的密钥去冒充你的小程序身份；
第三步，后端用自己的JWT token机制签发登录态，把openid等关键信息编码进token里，返回给小程序端。后续所有请求携带这个token，后端通过拦截器解析token得到当前用户。

给你看后端Controller的核心代码，就是这个过程中的主链路：

java复制@PostMapping("/login")
public Result<LoginResponse> login(@RequestBody LoginRequest request) {
    // 1. 调用微信接口获取openid
    String url = String.format(
        "https://api.weixin.qq.com/sns/jscode2session?appid=%s&secret=%s&js_code=%s&grant_type=authorization_code",
        appId, appSecret, request.getCode());
    String response = restTemplate.getForObject(url, String.class);
    JSONObject json = JSON.parseObject(response);
    String openid = json.getString("openid");
    if (StringUtils.isBlank(openid)) {
        return Result.error("登录失败，请稍后重试");
    }
    // 2. 查询或创建用户
    User user = userMapper.selectOne(new LambdaQueryWrapper<User>()
        .eq(User::getOpenid, openid));
    if (user == null) {
        user = new User();
        user.setOpenid(openid);
        user.setNickname("新用户");
        user.setRole("ROLE_USER");
        user.setCreateTime(LocalDateTime.now());
        userMapper.insert(user);
    }
    // 3. 签发JWT
    String token = jwtUtil.generateToken(user.getId(), user.getRole());
    return Result.success(new LoginResponse(token, user));
}

4.2 科普内容模块：富文本展示、阅读计数和语音播报的落法

科普文章模块看起来简单，实际有几个性能和安全方面的细节要处理。

首先是阅读计数的防刷。如果每次打开文章都直接update t_article的view_count，热点文章在高并发下会造成数据库行锁竞争。我的做法是先把阅读数写入Redis，比如incr article:view:{id}，然后每隔一段时间（比如5分钟）由定时任务批量同步到MySQL。虽然极端情况会有一点计数延迟，但对于内容社区来说完全够用，而且大幅降低数据库压力。

其次是语音播报的实现。这是老年用户特别需要的功能——看不完的文章可以听。我对比了两种方案：一是前端用微信同声传译插件，在用户端实时合成语音，不消耗服务端资源，但音色固定、合成质量一般；二是后端接入TTS服务（比如腾讯云语音合成）生成MP3文件存 OSS，前端直接播OSS地址。项目最终选了后者，因为预合成的音频可以带上情感语气，听感更像“有人讲故事”，而且用户播报不卡顿。同时TTS文本需要清理：要先把富文本里的HTML标签全部剥掉，只保留纯文本再送去合成，否则会读出div和span这种标签名，特别出戏。

4.3 社区交流：发帖、评论、点赞和“向平台提问”的交互设计

社区交流模块的核心不是技术而是信任感的建立。我设计了两个独立的入口：一个叫“大家聊防诈”，就是普通的BBS式帖子流；另一个叫“我来问问”，专门接收老人关于诈骗的疑问，由志愿者和管理员后台回答。后者的回复会带官方的“已核实”标识，这个标识对老年用户非常有效——他们需要一个明确的信号来区分“专业回答”和“普通网友热评”。

技术上，发帖前必须过两道检查：第一道是小程序端本地先跑一遍敏感词，拦截明显违规的内容；第二道是后端用HanLP分词+自定义诈骗关键词库做深度检查。值得注意的是，防诈平台的敏感词库不能只像通用社区那样过滤色情暴力和广告，它还得包含“转账”“安全账户”“验证码”“屏幕共享”这类高风险行为词。比如一条帖子写“我刚收到一条说我中奖的短信，让我先交2000块手续费才能领奖”，这显然是个需要重点关注的内容——也许发帖者是在求助，也许是在分享亲历，无论哪种，平台都应该主动触发风险提醒甚至人工介入。

社区帖子的缓存策略也有讲究。列表页热门帖子用Redis的zset存储当前时间窗口内的点赞数排行，而不是每次都去数据库做大排序。新发布的帖子默认进MySQL，后台定时刷新热点缓存，这个方案支撑几千日活用户一点问题没有。

在交互上，所有操作按钮都做成大块卡片式，发帖的输入框有语音输入入口（调用微信内置的录音转文字能力）。老年人打字慢是正常现象，语音输入能把发帖门槛降低一大截，这个设计长期使用下来反馈特别好。

5. 老年用户体验优化的几个关键细节

5.1 字号、布局和颜色的取舍：不是“设计审美”问题，而是“能不能用”问题

为老年人设计UI，第一条原则就是——宁可看起来“幼稚”，不可用起来“费劲”。我把设计稿的基础字号定在34rpx以上，标题直接56rpx，按钮最小高度88rpx，因为小程序里rpx会自动适配不同屏幕宽度，这个数值在大多数手机上都能保证清晰的阅读体验。

布局上全局禁止侧滑抽屉导航，因为老年人的手指拖拽精度不够；所有Tab和关键按钮固定在页面底部或中上部大块区域，避免在边缘安排可点元素。颜色方面，不要使用低对比度的浅灰色文字，正文用纯黑或深灰，背景保持纯白，状态强调色用大红色或大绿色——这里没有高级的莫兰迪色系，接受度最高的就是这些“传统”颜色。

这里要说一个容易触雷的地方：iOS的微信小程序里，字体如果小于12px会被系统强制调整，但安卓不会。所以不要依赖系统强制，统一在样式里写死适当大小字号，同时给所有文本容器设置足够的行高，避免文字挤压在一起。

5.2 语音提示与“一键求助”入口：关键时刻能救命

平台必须在任何页面都能快速触达两类操作：一是听语音，二是一键求助。

我在小程序全局tab中固定放了一个“求助”按钮，点击后进入紧急联系页，顶部是醒目的“拨打96110反诈专线”按钮，下面跟着“一键联系子女”的功能——直接调用wx.makePhoneCall拨打子女手机号。这里需要在用户设置里提前登记紧急联系人，默认从绑定的parent_user_id关联的子女账号里读取手机号。考虑到老人可能会误触，点击后弹窗确认，二次确认后才会真正拨号，这个双重确认流程不能再少了。

内容阅读页底部悬浮一个“语音播放”按钮，随时点击即可播放文章正文。语音按钮的触发区域做得很大，防止点错。同时文章页和社区页都支持阅读完成后自动弹出“把这条内容转发给子女”的引导按钮，利用微信自带的分享能力，让老人一键把有用信息同步给家庭群。

5.3 子女端绑定：一个被很多人忽略但价值巨大的设计

我在用户表里设计了parent_user_id字段，就是为“子女关怀”功能预留的。这个功能的出发点是：很多老人看防诈内容是不求甚解的，看过就忘，但子女可以帮忙把关。老人端可以在“设置”里生成一个家庭邀请二维码，子女用微信扫码后填入自己的手机号完成绑定。绑定后，子女端（用同一个微信小程序，后台自动切换角色）可以看到以下数据：

• 父母最近一周的科普内容阅读记录；
• 父母在社区里的提问和得到的回答；
• 平台检测到父母浏览了高风险的诈骗相关内容时，自动推送预警给子女。

这个功能的警示意义远大于功能本身。很多老人自己被骗了也不会告诉子女，但如果平台检测到他在深夜反复打开一篇名为“如何用手机理财挣大钱”的文章，子女侧能立刻收到推送，这种主动预警比事后补救有效得多。开发上并不复杂，就是维护一个简单的用户绑定关系加上针对高风险内容的定时扫描任务，但产品价值极大。

6. 防诈能力：内容审核、风险识别与举报处置

6.1 双层内容审核：机器过滤是底稿，人工审核是保障

社区类产品启动阶段，最怕的不是用户少，而是第一条垃圾帖就把氛围搞坏了。我设计了“机器初筛+人工终审”的双层机制。

机器初筛用HanLP做中文分词，配合自定义词库判断文本风险等级。词库分三级：一级是绝对违禁词（色情、暴力、违法违规，直接拦截），二级是高风险诈骗词（转账、验证码、安全账户、中奖、高收益理财等，触发后帖子进待审状态并在原文中高亮命中词），三级是敏感求助模式（规则正则匹配到“我是不是被骗了”“对方让我下某某App”这类模式时，直接推送到人工客服优先处理）。这个分级不是拍脑袋定的，而是基于大量真实诈骗话术样本统计出来的。用HanLP的原因，一是它对中文分词的支持在开源方案里准确率靠前，二是相比接第三方云服务，自己部署一套没有按次计费的成本压力。

我来给你看后端审核核心逻辑的大致样子：

java复制public CheckResult checkContent(String content) {
    List<String> words = hanlp.segment(content);
    CheckResult result = new CheckResult();
    result.setLevel(0);
    for (String word : words) {
        if (level1Words.contains(word)) {
            result.setLevel(2);
            result.setReason("包含违禁词:" + word);
            return result;
        }
        if (level2Words.containsKey(word)) {
            result.setLevel(1);
            result.getHitWords().add(word);
        }
    }
    // 命中的一级风险词超过2个，升级为待人工审核
    if (result.getHitWords().size() >= 2) {
        result.setLevel(2);
        result.setReason("命中多个诈骗高风险词，需人工审核");
    }
    return result;
}

人工终审不是一个独立后台系统，而是在小程序的项目里加了一个管理端入口，管理员登录后进入Web管理页面（复用同一套Spring Boot服务，只是接口和数据权限不同），可以浏览待审核帖子、查看机器命中词高亮、执行通过/删除/封号操作。

6.2 高风险内容主动预警的扫描逻辑

除了发帖审核，平台还需要主动扫描用户的阅读行为，识别高风险场景。我实现了一个轻量级的定时任务（Spring的@Scheduled注解），每10分钟扫描一次用户阅读行为表：

判断逻辑是：用户在连续30分钟内阅读超过3篇“高风险类型”的文章（比如涉及陌生链接、非正规投资理财导流），或者在同一篇文章上停留时间异常长（超过10分钟），就标记该用户为“风险关注用户”。标记后的用户会触发两个动作：一是平台内弹窗推送一条温和的提醒，“您可以点击这里咨询志愿者，或一键联系子女”；二是如果绑定了子女账号，给子女推送一条微信订阅消息。

这个功能上线后，收到的反馈让我很意外——不少子女用户说，这条推送成了他们跟父母沟通的契机，他们会主动打电话问“爸，我看你刚才在看理财的文章，是不是有人给你推荐什么了”，比平台自己打电话更有效。所以这套逻辑虽然技术难度不高，但把技术“翻译”成了人和人之间的关怀，价值一下就出来了。

6.3 举报与处置的闭环

举报功能不能只做“提交”就结束。我在后台设计了一个简单的工单流：

收到用户举报 → 生成待处理工单 → 管理员在后台查看被举报内容及上下文 → 判定（正常/违规）→ 如果是违规：删除内容、扣除信誉分，严重者封禁账号 → 处理结果回写举报记录，通过订阅消息通知举报人。

这个闭环里有一个容易被忽略的点：被举报人在被删除帖子时，最好能看到“您的帖子因违反社区公约已被移除”的说明，同时给一次申诉机会。如果直接静默删除，用户会一头雾水，甚至觉得平台乱删内容；如果给一次申诉入口，既体现了对用户的尊重，也减少了误伤带来的投诉。申诉表我放在和举报表同级的t_appeal里，字段包括target_id、appeal_reason、status，管理员审核后更新状态并通知用户。这套机制虽然增加了工作量，但对老年人社区来说尤其重要——老人对待遇公平非常敏感，申诉通道能避免很多信任危机。

7. 部署上线全流程与开发中踩过的坑

7.1 后端JDK 1.8环境打包到Docker Desktop的正确姿势

这个项目最终是部署到Docker环境跑的。最早我在本地起Spring Boot 2.7.8（JDK 8）开发完，准备打包成Docker镜像扔到自己的Docker Desktop上跑，结果一上来就被几个坑卡住了。

第一个坑是基础镜像的选择。我用的是openjdk:8-jdk-alpine这个镜像，但Alpine Linux默认的glibc和Spring Boot的某些依赖存在兼容性问题，启动时偶尔报字体相关的错。解决办法是换用eclipse-temurin:8-jdk-alpine，这个镜像做了完整的JDK运行环境适配，同样是Alpine却省心很多。

第二个坑是时区问题。Spring Boot应用打包到容器里，默认时区是UTC，日志和接口返回的时间跟北京时间差了8小时。解决方法是启动参数里加：

bash复制java -jar -Duser.timezone=Asia/Shanghai app.jar

或者更彻底点，在Dockerfile里加一行：

dockerfile复制ENV TZ=Asia/Shanghai
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

第三个坑是内存限制。默认的JVM在容器里会试图占用宿主机全部内存，导致Docker Desktop在Mac上经常卡死。需要在启动命令里显式声明堆内存：

bash复制java -Xms256m -Xmx512m -jar app.jar

Dockerfile最终长这样，供你直接参考：

dockerfile复制FROM eclipse-temurin:8-jdk-alpine
WORKDIR /app
COPY target/anti-fraud-platform.jar app.jar
ENV TZ=Asia/Shanghai
EXPOSE 8080
ENTRYPOINT ["java", "-Xms256m", "-Xmx512m", "-jar", "app.jar"]

构建命令也很简单：docker build -t anti-fraud-platform.jar .，然后 docker run -d -p 8080:8080 --name anti-fraud anti-fraud-platform.jar。

7.2 小程序登录失败的定位排查链路

开发中最让我头疼的一个问题是“小程序获取登录后的微信用户失败”，这个报错伴随的现象是：用户点击授权头像昵称后，后端始终拿不到正确的openid，日志里频繁出现“登录失败”和“无效的code”。

排查过程我总结成一条链路，非常值得你存下来备用：

第一步，检查前端wx.login()是否真的被调用了。有时候为了省事，开发者会把登录写在一个异步回调里，回调还没触发就发起了后续请求，导致拿到的code是空的。控制台打印一下code，确认非空。

第二步，检查后端调用code2Session时使用的appid和secret是否正确。最常见的坑是用了小程序测试号的凭据去连正式环境，或者小程序的AppSecret在微信公众平台被重置了但代码里没同步更新。我那次的问题就在这——同事在公众平台点了一下“重置密钥”，结果代码里的secret还是旧值，code肯定换不到openid。

第三步，检查code是否被重复使用。微信的code只能用一次，如果代码里因为重试机制把同一个code提交了两次，第二次必失败。解决方法是保证登录接口的幂等性——如果某个code已经消费过，就直接返回旧token或报错，而不是重复调用微信接口。

第四步，确认小程序后台的服务器域名已经配置。体验版和正式版的小程序都必须把后端接口的域名（要求HTTPS）配置到“开发设置-服务器域名”里，否则在小程序真机环境下请求会直接被拦截，报错信息还特别模棱两可。

最后，别忘了检查网络环境。小程序开发者工具默认可以绕过域名校验，但真机会严格校验。很多人习惯在开发者工具里开了“不校验合法域名”一路调试，结果统一发布后发现线上请求全部失败，就是这个原因。

7.3 小程序与微信后台相关的三类配置

接入微信生态，绕不开后台配置这块。我按项目推进中会用到的顺序，把三类配置梳理一下。

第一类是服务器域名。request合法域名、uploadFile合法域名、downloadFile合法域名都要填，而且必须是HTTPS，不能带路径。开发阶段可以把“不校验合法域名”打开，但上线前必须关掉，并确保域名已经备案。要注意，你开发时常用的IP不能在正式环境下当作request域名使用，除非你有证书，否则一定得挂一个HTTPS域名。

第二类是业务域名。如果小程序里要打开公众号文章或web-view嵌入页面，就必须配置业务域名。这里有个很现实的问题——配置业务域名需要把校验文件上传到对应网站根目录，很多个人开发者卡在这一步。如果你只是想让用户阅读公众号文章，更简单的替代方案是用小程序自身的web-view打开文章链接前，先让用户复制链接到浏览器，或者直接把文章内容转存成小程序内的富文本排版。灵活处理，别把自己困在流程里。

第三类是推送消息配置。小程序要发订阅消息（比如给子女推送风险预警），必须在小程序后台申请对应模板，并拿到模板ID。这里的坑在于：订阅消息需要用户主动授权，而且一次性订阅只能下发一次。如果用户没授权，后台无论如何都推送不出去。所以我设计了兜底方案——实时预警除了推送订阅消息，还会同步给用户发送手机短信（需要用户在小程序里绑定手机号），短信不受订阅次数限制，适合这种低频但高价值的通知。

7.4 开发中遇到的Spring Boot基础坑：事务失效和循环依赖

后端开发过程中还踩过两个比较典型的Spring Boot基础坑，一并写出来，多提醒一个算一个。

事务失效是我早期犯过的错误。我在一个Service方法上加了@Transactional，但方法里有个内部自调用——在同一个类里另一个方法调用了这个带事务的方法，结果事务完全没生效。原因是Spring的声明式事务走的是AOP代理，内部自调用时调用的是this对象而不是代理对象，所以注解被忽略了。解决方案很简单：把需要事务的方法拆到单独的Service Bean里，或者自己注入自身的代理对象。这条规则，面试题里经常有，实际开发中也真的会踩。

循环依赖是另一个经典。我设计Service层时，A服务需要调用B服务，B服务同时又需要A服务，结果Spring启动直接报错“BeanCurrentlyInCreationException”。Spring Boot 2.6版本以后默认不允许循环依赖，解决方式最好是从设计层面打破环——把公共逻辑抽到C服务里，A和B都依赖C，结构立刻清晰。不要图省事去开allow-circular-references配置，那只是掩盖问题，后续维护成本极高。

7.5 上线后的运营侧建议：内容先行，冷启动别靠功能

技术上线只是第一步。这个平台如果冷启动做不好，功能再完善也没人用。我这里根据运营中实际摸索的经验给几条建议：

第一，种子内容必须提前准备好。上线前至少准备五十篇以上分类齐全的科普文章，覆盖电话诈骗、保健品诈骗、投资理财诈骗、冒充公检法、网络购物退款等高频类别。文章要写得口语化、短段落，每篇配上语音版。老人点开一个新平台，如果看不到多少内容，关掉可能就不再来了。

第二，先拉一小批“社区种子用户”。找身边愿意尝试新事物的退休长辈，教他们用，让他们在社区里发帖聊天。这批种子用户不需要多，几十个就够，但一定要活跃——他们的帖子会成为社区的第一批内容，是新用户进来的参照物。

第三，定期整理“典型骗局日历”。比如假期前后冒充机票退改签增多，春节前后中奖倒卖骗局多发，平台可以根据时间节点提前准备科普方向，做成小专栏。这比随机更新内容更贴近老年用户的生活，粘性自然会提高。

整套平台从需求梳理到上线，前后花了我四个多月。现在回看，技术上其实没有特别复杂的东西——Spring Boot那套框架应用、小程序生态对接、基础的内容审核和社区功能，都是常规开发。真正的难点在于把“防诈”这个宏大的命题，拆解成“大字、语音、可提问、有出口、子女可关怀”这样一个个具体且贴合的细节。老年人的网络安全不是靠一个冷冰冰的App就能解决的，它需要内容、社区、家人和平台技术共同配合。希望这篇分享能给正在做或准备做类似方向的朋友一些参考，哪怕只是避免一个坑，也不算白写。