布局图1. “旅行搭子”不是玄学——系统需求解构与功能边界
这两年“搭子文化”在旅游圈火得很，年轻人出门不愿意跟团，又不想一个人扛着行李拍照没人帮忙，于是“旅行搭子”成了刚需。但如果你真的动手做过这类产品，会发现市面上绝大多数“搭子社交”都死在了同一个问题上：光有聊天室，没有可落地的行程结构。聊了半天，两个人连目的地、天数、预算都没对齐，最后不了了之。
这个项目本质上是一套以“旅行攻略+搭子匹配”为双核心的内容与社交平台。它不是一个简单的聊天应用，而是把“攻略浏览—行程规划—匹配同游—组队出行”整个链路打通了。更关键的是，这套系统从设计之初就瞄准了多端覆盖：微信小程序、公众号H5、独立APP、浏览器H5，四端共用一套Java后端。这也决定了它的架构方案不能像做个单端Demo那么随意。
我在拆解这类系统时，习惯先画一张功能边界图，把“必须有、最好有、先不做”三档分清楚。这套系统的MVP级别功能是这样的：
- 用户体系：手机号登录、微信生态登录（小程序code换session、公众号OAuth）、APP端账密登录。
- 内容模块：旅行攻略的发布、编辑、审核、详情展示，支持图文混排，这是旅行平台的流量入口。
- 行程规划：用户可以把目的地、日期、景点、住宿、餐饮做成结构化行程单，分享给搭子预览。
- 搭子匹配：基于目的地、出发时间、旅行偏好标签做推荐和主动搜索，这是区别于普通游记平台的核心差异点。
- 互动模块：站内私信聊天、搭子申请、组队确认。
- 管理后台：内容审核、用户管理、举报处理、数据统计。
先不做的是哪些？支付闭环、旅行社入驻、在线订票。这几个模块一加进来，系统复杂度会立刻翻倍，涉及资质、资金安全、第三方对接，对早期项目来说属于“活下去之后再想的事”。这套系统的价值在于先用搭子社交和攻略内容把用户留住，商业化是后话。
我还想多说一句关于“旅行搭子”这个词的理解。它不等于“陌生人社交”，更不等于“相亲交友”。用户的核心诉求是“找到能一起走完这段路的人”，所以匹配算法里最关键的字段是行程兼容度，而不是兴趣爱好有多重合。很多人做这类产品时把算法重点放在兴趣标签上，这是本末倒置。兴趣爱好可以锦上添花，但行程时间、预算区间、出行节奏是否匹配，才是真正的决策变量。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型：JAVA系方案为什么适合这类多端社交产品
2.1 后端框架：Spring Boot是绕不开的基座
网上经常有人问，做这类系统用Node.js、Python行不行？我的回答是：行，但Java有它不可替代的优势。首先是生态成熟度，Spring Boot全家桶覆盖了权限、缓存、消息、持久化、定时任务几乎所有基建，团队招人也好招，薪资水平体系透明，代码风格可控性强。其次，旅行社交系统一定会涉及IM、推送、定时任务、第三方支付，这些场景Java都有经过大规模验证的解决方案，出问题的概率更低。
这套系统的标准技术栈我建议这样搭：
| 层级 | 技术选型 | 说明 |
|---|---|---|
| 基础框架 | Spring Boot 2.7.x + Spring Cloud Alibaba（可选） | 主推单体起步，业务量上来后再拆微服务 |
| ORM | MyBatis-Plus | 单表CRUD效率高，配合SQL优化 |
| 数据库 | MySQL 8.0 + Redis 7 | MySQL存业务数据，Redis扛会话与热点 |
| 鉴权 | Spring Security + JWT | 无状态会话，适配多端 |
| 搜索 | Elasticsearch（可选） | 攻略全文检索，1万用户量级可以先不引入 |
| 文件存储 | 阿里云OSS / MinIO | 图文内容必须走对象存储，不能存本地磁盘 |
| IM | Netty自研 / 腾讯云IM / 环信 | 见第4章专门讨论 |
| 定时任务 | XXL-JOB | 搭子过期提醒、内容定时发布 |
我的建议是初期不要上微服务。很多项目死在过早拆分上，一个几百人同时在线的系统，单体+缓存+读写分离完全能撑住。先把业务跑通，等出现“多人同时编辑行程导致锁竞争”“IM和业务相互抢占CPU”这类真实压力时，再拆也来得及。
2.2 前端多端方案：一套代码跑四个端的取舍
小程序、公众号、APP、H5四端都做，如果每个端都原生开发，至少需要3到4个前端团队，对绝大多数创业团队来说不现实。这里采用的方案是 uni-app 跨端框架，一套Vue语法编译到微信小程序、支付宝小程序、H5、iOS/Android App。
先说为什么选uni-app而不是React Native或Flutter。RN和Flutter在App端的体验确实更接近原生，但它们的短板在于：小程序和公众号仍然需要单独开发，做不到“一套代码全线通吃”。uni-app虽然App端的流畅度略逊于Flutter，但对内容型产品来说，用户体验的差距没有想象中那么大，换来的是开发效率的成倍提升。
真正需要花心思的是条件编译。比如小程序端需要用uni.login()获取code，H5端需要处理微信内浏览器的OAuth跳转，App端要调原生SDK做微信分享。这些端差异是不能写在同一个文件里硬跑通路的，必须用条件编译分开写。
3. 小程序/公众号/APP/H5四端共用的核心架构逻辑
3.1 云端多端会话体系：Token是唯一的身份证
四端并存最容易踩的坑是登录态不一致。小程序里有wx.login()换出来的openid，公众号里有OAuth授权换出来的code，APP里有手机号+验证码登录，H5呢？H5有时候在家就在企业微信里打开。如果每个端各搞一套Session，用户从公众号跳小程序、从小程序下载App后，账号全部对不上，数据散成碎片，这在产品层面是致命的。
所以这套系统的会话设计必须遵循一个原则：openid、unionid、手机号都只是账号绑定的凭证，真正的前端会话凭证只有JWT Token。
登录流程统一拆成两步：
- 各端拿到自己的临时凭证（小程序code、公众号code、App的设备标识），请求后端
/auth/login接口。 - 后端通过凭证解析出对应的openid/unionid，去用户表里查是否已经绑定。若未绑定，返回
need_bind_phone状态码，前端弹出手机号绑定页；若已绑定，签发JWT Token返回。
这里有个前端的实现细节：小程序在页面栈的全局请求拦截器里，统一注入Authorization: Bearer <token>头，任何接口返回401就在全局处理，跳转到登录页。H5端则要把Token存在localStorage而不是sessionStorage，否则用户从公众号菜单进入一个页面，关闭再打开时登录态就丢失了。
3.2 API设计：多端复用下的参数与返回码规范
四端共用一套后端接口，最忌讳的就是某一端特有逻辑侵入公共接口。我在项目里定了一条硬性规定：接口参数和返回结构不允许出现平台专属字段。比如登录接口的入参统一