旅行搭子系统架构实战：Spring Boot多端设计与匹配算法解析

1. “旅行搭子”不是玄学——系统需求解构与功能边界

这两年“搭子文化”在旅游圈火得很，年轻人出门不愿意跟团，又不想一个人扛着行李拍照没人帮忙，于是“旅行搭子”成了刚需。但如果你真的动手做过这类产品，会发现市面上绝大多数“搭子社交”都死在了同一个问题上：光有聊天室，没有可落地的行程结构。聊了半天，两个人连目的地、天数、预算都没对齐，最后不了了之。

这个项目本质上是一套以“旅行攻略+搭子匹配”为双核心的内容与社交平台。它不是一个简单的聊天应用，而是把“攻略浏览—行程规划—匹配同游—组队出行”整个链路打通了。更关键的是，这套系统从设计之初就瞄准了多端覆盖：微信小程序、公众号H5、独立APP、浏览器H5，四端共用一套Java后端。这也决定了它的架构方案不能像做个单端Demo那么随意。

我在拆解这类系统时，习惯先画一张功能边界图，把“必须有、最好有、先不做”三档分清楚。这套系统的MVP级别功能是这样的：

• 用户体系：手机号登录、微信生态登录（小程序code换session、公众号OAuth）、APP端账密登录。
• 内容模块：旅行攻略的发布、编辑、审核、详情展示，支持图文混排，这是旅行平台的流量入口。
• 行程规划：用户可以把目的地、日期、景点、住宿、餐饮做成结构化行程单，分享给搭子预览。
• 搭子匹配：基于目的地、出发时间、旅行偏好标签做推荐和主动搜索，这是区别于普通游记平台的核心差异点。
• 互动模块：站内私信聊天、搭子申请、组队确认。
• 管理后台：内容审核、用户管理、举报处理、数据统计。

先不做的是哪些？支付闭环、旅行社入驻、在线订票。这几个模块一加进来，系统复杂度会立刻翻倍，涉及资质、资金安全、第三方对接，对早期项目来说属于“活下去之后再想的事”。这套系统的价值在于先用搭子社交和攻略内容把用户留住，商业化是后话。

我还想多说一句关于“旅行搭子”这个词的理解。它不等于“陌生人社交”，更不等于“相亲交友”。用户的核心诉求是“找到能一起走完这段路的人”，所以匹配算法里最关键的字段是行程兼容度，而不是兴趣爱好有多重合。很多人做这类产品时把算法重点放在兴趣标签上，这是本末倒置。兴趣爱好可以锦上添花，但行程时间、预算区间、出行节奏是否匹配，才是真正的决策变量。

2. 技术选型：JAVA系方案为什么适合这类多端社交产品

2.1 后端框架：Spring Boot是绕不开的基座

网上经常有人问，做这类系统用Node.js、Python行不行？我的回答是：行，但Java有它不可替代的优势。首先是生态成熟度，Spring Boot全家桶覆盖了权限、缓存、消息、持久化、定时任务几乎所有基建，团队招人也好招，薪资水平体系透明，代码风格可控性强。其次，旅行社交系统一定会涉及IM、推送、定时任务、第三方支付，这些场景Java都有经过大规模验证的解决方案，出问题的概率更低。

这套系统的标准技术栈我建议这样搭：

我的建议是初期不要上微服务。很多项目死在过早拆分上，一个几百人同时在线的系统，单体+缓存+读写分离完全能撑住。先把业务跑通，等出现“多人同时编辑行程导致锁竞争”“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。

登录流程统一拆成两步：

1. 各端拿到自己的临时凭证（小程序code、公众号code、App的设备标识），请求后端/auth/login接口。
2. 后端通过凭证解析出对应的openid/unionid，去用户表里查是否已经绑定。若未绑定，返回need_bind_phone状态码，前端弹出手机号绑定页；若已绑定，签发JWT Token返回。

这里有个前端的实现细节：小程序在页面栈的全局请求拦截器里，统一注入Authorization: Bearer <token>头，任何接口返回401就在全局处理，跳转到登录页。H5端则要把Token存在localStorage而不是sessionStorage，否则用户从公众号菜单进入一个页面，关闭再打开时登录态就丢失了。

3.2 API设计：多端复用下的参数与返回码规范

四端共用一套后端接口，最忌讳的就是某一端特有逻辑侵入公共接口。我在项目里定了一条硬性规定：接口参数和返回结构不允许出现平台专属字段。比如登录接口的入参统一是auth_type和auth_code，不要写成wx_mini_code和wx_oauth_code，后端的适配逻辑全部收敛在AuthService内部。

返回码也做了统一规划：

我特别想强调601和602这两个业务码。很多团队把“需要绑定手机号”简单地和“未登录”混在一起，结果用户在小程序里已经微信授权了，却因为强制要求绑定手机号而卡在半路。而搭子申请的“过期”更是不能忽略的场景，用户看到一条一个月前的搭子申请还在“待处理”状态，产品信任感直接就崩了。业务码要细分，前端才能做出正确的交互反馈。

4. 搭子匹配与即时通讯：这套系统最核心的落地实现

4.1 匹配不是玄学推荐，而是结构化筛选+轻量评分

很多产品一做匹配就想上协同过滤、深度学习，我劝你别。对于早期旅行搭子产品，数据量根本支撑不起复杂模型，用户画像的稀疏程度会让所有算法都失效。最适合的方案是规则筛选为主、标签评分为辅。

核心匹配字段有四组：

服务端代码核心逻辑是这样的：

java复制public List<MateCandidate> matchTravellers(MatchQuery query) {
    // 第一步：SQL硬条件过滤，把明显不合适的先排除掉
    LambdaQueryWrapper<TravellerProfile> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(TravellerProfile::getDestinationCity, query.getDestinationCity())
           .le(TravellerProfile::getStartDate, query.getEndDate())
           .ge(TravellerProfile::getEndDate, query.getStartDate())
           .le(TravellerProfile::getBudgetMin, query.getBudgetMax())
           .ge(TravellerProfile::getBudgetMax, query.getBudgetMin())
           .ne(TravellerProfile::getUserId, query.getUserId());
    List<TravellerProfile> candidates = travellerProfileMapper.selectList(wrapper);

    // 第二步：内存中对候选列表做标签重叠度评分
    candidates.forEach(candidate -> {
        int score = 0;
        score += candidate.getTravelStyle().equals(query.getTravelStyle()) ? 30 : 0;
        score += overlapDays(query.getDateList(), candidate.getDateList()) * 10;
        score += candidate.getPreferenceTags().containsAll(query.getPreferenceTags()) ? 20 : 0;
        candidate.setMatchScore(score);
    });

    // 第三步：评分降序，剔除分数过低的对象
    return candidates.stream()
        .filter(c -> c.getMatchScore() >= 50)
        .sorted(Comparator.comparingInt(TravellerProfile::getMatchScore).reversed())
        .limit(20)
        .collect(Collectors.toList());
}

你发现没有，这段代码里我刻意没有用数据库算分数、排序，原因是：匹配池本身不会大到让全表扫描成为性能瓶颈，而内存中的集合操作可以把“评分算法调整”的成本降为零。产品经理改匹配规则的时候，你只需要改这段Java代码，不需要为了SQL语句的写法头疼。

实际操作中还有一个容易忽略的点：一次匹配请求要同时返回“空闲中”和“已组队但缺人”两类用户。很多想找搭子的人其实不介意加入一个已经有两三个人的小队伍，所以group_status字段一定要进入筛选条件。

4.2 即时通讯的选型：自研还是用第三方云服务

这是这类项目最纠结的技术决策点。我先给结论：用户量在5万以下，直接用第三方IM；日活到了10万、老板又说要控制成本的时候，再考虑自研。

第三方IM我实测过腾讯云IM和环信。腾讯云IM在微信生态内体验最好，消息触达率稳定，而且支持直接在微信小程序里跑，不需要自己处理WebSocket长连接的各种边界问题。环信的优势是接口相对简单，但如果你需要复杂消息卡片（比如行程单卡片、搭子申请卡片），自定义消息体的工作量并不小。

如果用第三方IM，后端要做的核心事情是两件：

1. 通过服务端API批量注册IM账号，把IM的userSig（签名凭证）和业务用户ID绑定。
2. 在搭子匹配成功后，后端自动调用IM的REST API创建一个单聊会话，并推送一条系统欢迎消息。这样用户看到的不是“怎么跟对方私聊”的困惑，而是已经有人主动打招呼了。

这里分享一个我踩过的坑：第三方IM的离线推送在小程序端和APP端是两套完全不同的配置。小程序端可以用微信订阅消息做离线提醒，但订阅消息的一次性订阅限制非常烦人；APP端需要厂商推送通道（小米、华为、OPPO、vivo）逐个接入。如果项目排期紧，我的建议是：先把在线聊天做顺，离线推送放到二期，否则光适配厂商推送的SDK就够你折腾两周。

4.3 搭子申请的状态机

搭子匹配不是两个人互点了“我喜欢”就完事了，中间有一个非常容易出bug的状态流转：申请、待确认、已接受、已拒绝、已过期、已完成、已取消。

我强烈建议开发者用状态机来管理这个流程，而不是用一堆零散的if-else。状态机的核心规则：

Java里做状态机不必引入大型框架，用枚举+Map就能实现得很优雅：

java复制public enum MateOrderState {
    PENDING("待确认"),
    ACCEPTED("已接受"),
    REJECTED("已拒绝"),
    EXPIRED("已过期"),
    CANCELLED("已取消"),
    FINISHED("已完成");

    public static final Map<MateOrderState, List<MateOrderState>> TRANSITIONS =
        Map.ofEntries(
            Map.entry(PENDING, List.of(ACCEPTED, REJECTED, EXPIRED)),
            Map.entry(ACCEPTED, List.of(CANCELLED, FINISHED))
        );

    public boolean canTransit(MateOrderState target) {
        return TRANSITIONS.getOrDefault(this, List.of()).contains(target);
    }
}

然后合法的状态变更全部收口在一个方法里，不做任何绕过状态机的操作。这个设计的好处是：后台管理时直接选用途枚举，不会出现“已拒绝的订单又被改成已完成”之类的脏数据。

5. 数据库模型设计：攻略、行程、用户关系怎么落表

5.1 关键表结构设计思路

一说到数据库设计，很多新手就急着给每个功能建表，结果表之间散成一盘沙。我做这类系统的习惯是：先把“用户—内容—关系”三个维度画清楚，再落表。

单体应用阶段的表结构我并不建议做得太范式化，适度冗余可以大幅减少联表查询。以这个系统为例，核心表可以划分为如下几组：

用户域

• user_account：用户主表，保存手机号、昵称、头像、性别、注册时间。
• user_auth：第三方授权绑定表，保存openid、unionid、平台类型，一个用户可以绑定多个平台。
• user_profile：旅行画像表，保存出发城市、偏好标签、预算区间、旅行节奏、个人简介。这个表的字段直接服务于搭子匹配，匹配接口查的就是这张表。

内容域

• travel_notes：攻略主表，保存标题、封面、目的地、出行月份、人均预算、浏览量、点赞量。
• notes_content：攻略内容详情表，保存富文本正文的JSON结构。
• travel_plan：行程规划表，一个用户可以有多个行程，对应不同的目的地和时间段。
• plan_day_item：行程每日明细表，保存某一天的景点、餐厅、酒店安排，这是搭子申请时分享给对方的关键数据。

社交域

• mate_order：搭子匹配订单表，保存申请人、被申请人、关联的行程ID、状态、匹配分数。
• mate_message：站内私信表（如果IM用第三方云，这张表只存系统通知和业务消息）。
• user_follow：关注关系表。

5.2 一张值得参考的行程表DDL

下面给出一份travel_plan和plan_day_item的简化DDL，你可以直接复制去用：

sql复制CREATE TABLE `travel_plan` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` bigint(20) unsigned NOT NULL COMMENT '创建者用户ID',
  `plan_title` varchar(100) NOT NULL COMMENT '行程标题',
  `destination_city` varchar(50) NOT NULL COMMENT '目的地城市',
  `destination_lat` decimal(10,6) DEFAULT NULL COMMENT '目的地纬度',
  `destination_lng` decimal(10,6) DEFAULT NULL COMMENT '目的地经度',
  `start_date` date NOT NULL COMMENT '出发日期',
  `end_date` date NOT NULL COMMENT '结束日期',
  `budget_min` int(11) DEFAULT NULL COMMENT '预算下限（元）',
  `budget_max` int(11) DEFAULT NULL COMMENT '预算上限（元）',
  `travel_style` tinyint(4) DEFAULT NULL COMMENT '旅行风格：1休闲 2特种兵 3摄影 4美食',
  `cover_url` varchar(500) DEFAULT NULL COMMENT '封面图',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '状态：0草稿 1发布 2已完成',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_user_id` (`user_id`),
  KEY `idx_destination_city` (`destination_city`),
  KEY `idx_start_date` (`start_date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='旅行行程主表';

CREATE TABLE `plan_day_item` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `plan_id` bigint(20) unsigned NOT NULL COMMENT '所属行程ID',
  `day_index` tinyint(4) NOT NULL COMMENT '第几天',
  `item_type` tinyint(4) NOT NULL COMMENT '1景点 2餐厅 3酒店 4交通',
  `item_name` varchar(200) NOT NULL COMMENT '项目名称',
  `item_desc` varchar(1000) DEFAULT NULL COMMENT '描述',
  `start_time` varchar(20) DEFAULT NULL COMMENT '开始时间，如09:30',
  `lat` decimal(10,6) DEFAULT NULL COMMENT '纬度',
  `lng` decimal(10,6) DEFAULT NULL COMMENT '经度',
  `address` varchar(500) DEFAULT NULL COMMENT '地址',
  `cost` int(11) DEFAULT NULL COMMENT '预估花费（元）',
  `sort_order` int(11) NOT NULL DEFAULT '0' COMMENT '排序',
  PRIMARY KEY (`id`),
  KEY `idx_plan_id` (`plan_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='行程每日明细表';

注意几个设计细节。第一，destination_lat/lng是冗余字段，但绝对值得冗余，因为匹配“同城出发”的用户时，只查这两列就行，不需要去POI表关联查询。第二，travel_style用tinyint存枚举值而不是直接存字符串，既节省空间，后续扩展风格枚举时也不需要改表结构。第三，plan_day_item里的sort_order必须存在，没有排序字段的行程明细在App端展示时一定会出现乱序的bug。

5.3 附近的人与目的地筛选用MySQL还是ES

这套系统有个高频场景是“查看去往同一目的地的搭子”，如果做到二三十万用户量，travel_plan表的数据量在几百万行左右，用idx_destination_city加时间范围过滤，MySQL完全能扛住。真正需要考虑上Elasticsearch的是攻略全文搜索的场景，但初期用MySQL的LIKE '%关键词%'也能对付，ES可以等搜索结果质量成为痛点后再接入。

关于“附近的搭子”这个功能，我个人的建议是砍掉它。旅行搭子的核心匹配维度是目的地和时间，不是物理距离。用户出发前在首页搜索目的地，看到同样计划去大理、时间重叠的人，远比在附近3公里找一个也想去大理的人更有意义。为了做“附近”功能引入Redis GEO或者MySQL空间索引，性价比很低。

6. 多端联调与上线部署：实测中那些绕不开的坑

6.1 小程序登录与公众号OAuth的session差异

做多端系统，前端联调至少有三分之一的精力是消耗在登录流程上的。这里有一个特别容易踩的坑：小程序端的wx.login获取的code有效期只有5分钟，而且只能用一次。如果前端拿code去后端换登录态时网络抖动失败，前端重新调用wx.login获取新的code再去换，不然会报invalid code错误。

公众号H5的OAuth网页授权则完全不同：code有效期同样是5分钟，但换取的是access_token和openid，而且这个access_token和普通接口调用的access_token不是同一个。很多人在公众号里调用wx.config分享SDK时，把两种token搞混，导致签名失败。我的经验是：后端单独封装一个WechatAuthService，把所有微信侧的逻辑全部隔离在里面，不暴露给前端任何细节，前端只需要知道“调这个接口会返回什么”。

6.2 H5分享卡片与URL签名

四端里我耗费精力最多的其实是H5分享卡片。公众号里用户把攻略分享到微信群，必须带上一张精美的卡片（标题+缩略图+简介），这需要调用微信JS-SDK的wx.updateAppMessageShareData接口。而调用这个接口的前提是后端生成正确的签名。

签名生成的坑主要在两个地方：一是URL必须用window.location.href.split('#')[0]截掉hash部分，否则签名会失败；二是缓存的jsapi_ticket必须设置7200秒的过期时间，每次重新拉取会导致接口性能下降。我把签名校验代码贴出来，这段代码基本可以直接复用：

java复制public String generateJsSdkSignature(String url, String jsapiTicket) {
    Map<String, String> paramMap = new TreeMap<>();
    paramMap.put("jsapi_ticket", jsapiTicket);
    paramMap.put("noncestr", UUID.randomUUID().toString().replace("-", ""));
    paramMap.put("timestamp", String.valueOf(System.currentTimeMillis() / 1000));
    paramMap.put("url", url);
    StringBuilder sb = new StringBuilder();
    paramMap.forEach((k, v) -> sb.append(k).append("=").append(v).append("&"));
    sb.deleteCharAt(sb.length() - 1);
    return DigestUtils.sha1Hex(sb.toString());
}

注意TreeMap保证参数按字典序排序，这是微信签名的硬性要求，顺序错了签名校验一定过不去。

6.3 Nginx反向代理与文件上传的经典配置

部署层面，我用的是传统但稳妥的方案：Nginx + Spring Boot Jar包 + MySQL + Redis。服务器配置4核8G起步，初期完全够用。

Nginx配置里有个容易忽略的坑：client_max_body_size默认只有1MB，用户在App端上传旅行照片时，一张手机原图动辄5MB，直接报413错误。这个参数必须显式调大：

nginx复制server {
    listen 80;
    server_name travel.example.com;

    client_max_body_size 20m;

    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        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_read_timeout 60s;
    }
}

图片存储我建议直接用阿里云OSS，MinIO虽然开源免费，但你要自己处理备份、CDN加速、防盗链，运维成本不低。OSS的PutObject接口配好上传凭证，前端直传，不走应用服务器中转，避免带宽成为瓶颈。

6.4 安全运维：评论防刷、接口幂等、SQL注入

多端系统上线后，最先遇到的安全问题不是黑客攻击，而是羊毛党和垃圾内容。我建议在网关层做三件事：

1. 接口限流：用Redis实现简单的令牌桶，每个用户每分钟最多请求60次，每个IP每分钟最多请求300次。特别是发送私信和提交搭子申请这两个接口，限流阈值要更严。

java复制public boolean tryAcquire(String key, int maxCount, int windowSeconds) {
    Long count = redisTemplate.opsForValue().increment(key);
    if (count == 1) {
        redisTemplate.expire(key, windowSeconds, TimeUnit.SECONDS);
    }
    return count <= maxCount;
}

2. 敏感词过滤：攻略标题、用户昵称、私信内容，统一走离线词库过滤。Java生态里用HanLP分词再加自定义敏感词表，命中直接替换为*。

3. SQL注入防护：拼SQL的风气一定要从代码审查上杜绝。MyBatis-Plus的QueryWrapper本身是预编译的，但如果有人在业务里写了${}传参，就存在注入风险。项目组可以加一个简单的代码扫描规则，发现${}直接报警。

我遇到过最经典的事故是：一个用户通过攻略搜索接口的排序参数注入了一段SQL，导致列表页直接报了数据全量泄漏的错误日志，好在当时数据库账号权限只开了DML没开DDL，损失不大。但还是让人出了一身冷汗，从那之后我规定所有排序字段必须走白名单映射，前端传什么字段都只当索引看，不做字符串拼接。

7. 从Demo到上线的个人实操心得

如果这个项目你是拿来学习，或者打算真刀真枪上线，我给你几条掏心窝子的建议。

第一，先把小程序单端跑通，再谈四端适配。 市面上很多项目Demo号称“支持多端”，实际是把一套代码复制了四份改改样式。这种做法既浪费资源又难以维护。我建议先用uni-app把小程序端完整跑通，确认核心链路（搜索攻略、发起搭子申请、聊天）没有问题，再编译到H5验证，最后才是App端。App端的适配工作其实最少，因为uni-app的App端和H5端在绝大多数页面布局上是一致的，主要处理的是推送和分享SDK的差异。

第二，搭子匹配的“过期”逻辑一定要做成定时任务，而不是用户下次打开才触发。 很多人为了省事，在查询匹配列表时判断if (create_time < now - 48h) updateState(EXPIRED)，这个逻辑在数据量小时看不出问题，一旦列表变大，每次查询都触发一堆更新，数据库压力立刻上来。正确做法是XXL-JOB每小时跑一次，批量把过期的mate_order状态更新掉。

第三，后端接口的返回结构不要用Map散装，统一用一个响应体。 我见过很多团队，一个接口返回的是JSON对象，另一个接口返回的是数组，前端联调时满屏的防御性判断。这是从项目第一天就该定死的规范：

java复制@Data
public class ApiResult<T> {
    private int code;
    private String message;
    private T data;
    private long timestamp = System.currentTimeMillis();

    public static <T> ApiResult<T> success(T data) {
        ApiResult<T> result = new ApiResult<>();
        result.code = 200;
        result.message = "success";
        result.data = data;
        return result;
    }

    public static <T> ApiResult<T> error(int code, String message) {
        ApiResult<T> result = new ApiResult<>();
        result.code = code;
        result.message = message;
        return result;
    }
}

第四，不要把用户生成的攻略正文直接存纯HTML。 富文本编辑器在小程序端和H5端渲染HTML的能力不同，小程序端的rich-text组件对HTML标签的支持有限制，很多样式会丢失。我的做法是编辑器保存一套JSON结构（段落、图片、标题），渲染时各端分别适配。虽然开发量略增，但用户体验才是一致的。

第五，关于“旅行搭子”匹配准确度，上线后要用数据验证而不是拍脑袋。 我在系统里给每个订阅的匹配加了点击率、接受率埋点。如果某个筛选条件（比如预算区间重叠校验）导致匹配数量为零的比例特别高，就要重新审视这个条件是否太严格。数据观测一段时间后发现，预算区间重叠约束在匹配成功中的权重其实没那么高，用户更在乎的是出行时间是否重合。后来把预算匹配从硬条件改成软条件，匹配成功率明显提升。

最后，聊聊这套系统的演进方向。代码跑通、用户量上来后，有两个方向值得投入：一是群组功能，把单对单的搭子匹配扩展成“同路线结伴群”，产品粘性会有质的提升；二是行程智能推荐，基于历史热门行程数据和POI数据，给用户生成半自动化的行程草稿，这会让“旅行攻略”从浏览型内容变成真正可执行的工具。但这些都是后话了，先把这篇文章里的架构和坑解决，一套稳定、可多端运行、匹配逻辑清晰的旅行搭子平台，就已经跑在绝大多数同类项目前面了。