2023年携程春招技术通用岗第四批笔试大概是我今年参加过的几场大厂笔试里综合体验比较有代表性的一场。携程的笔试风格跟字节、阿里那种上来就硬核算法开道的不太一样它更在意“你有没有认真用过携程的产品”或者更准确地说你懂不懂一个成熟OTA平台的业务逻辑和技术选型思路。这篇文章我不打算写成标准的面经流水账而是想把这批笔试里值得琢磨的点拆开讲透包括题型分布、算法题的解题思路、业务场景题的回答框架以及我踩过的坑和复盘心得给后面准备携程笔试的同学一个可以直接参考的路线。先说结论携程春招技术岗的笔试整体难度中等偏上不算难到离谱但非常考验临场状态和时间分配。第四批的试卷结构大概是四个部分专业知识选择题单选加多选混合、逻辑推理其实就是行测风格、技术算法编程题两到三道以及一道业务场景设计题。这几个部分里面算法题的代码量不算大地图题偏应试技巧真正拉开差距的其实是最后的业务场景题它要求你不光会写代码还得会用技术方案去解决一个具体的旅游业务问题。1. 笔试整体结构与考察逻辑1.1 这批试卷的科目组成我拿到的第四批技术通用岗试卷总共是四个板块限时大概100分钟左右具体时间记不太清了但节奏是比较紧的。当时群里不少同学说没做完主要就是卡在了后面的场景题上所以“时间分配”这四个字我觉得是整场笔试里最值得提前规划的一件事。先列一下我实际遇到的科目构成专业知识选择题约20道涵盖数据结构、计算机网络、操作系统、数据库基础、Java/Python语法相关的选择题少量多选。逻辑推理题约10道数列找规律、图形推理、文字逻辑判断偶尔有一两道简单的概率计算。编程算法题2道一道是中等偏下的数组/字符串题一道是稍微需要思考的搜索或动态规划问题。业务场景设计题1道给一个具体的携程业务场景要求用文字或伪代码描述技术方案。1.2 为什么携程要这么设计笔试说实话第一次看到这种结构我的第一反应是“怎么混进了行测题”。但复盘之后我发现携程这种设计是有明确意图的。像逻辑推理部分大厂笔试里阿里、腾讯偶尔也会用但比例没这么高。它考察的其实就是你在信息不完全的情况下做判断和推理的能力这跟做业务时“从模糊的需求里找到关键约束”其实是相通的。专业知识选择题则考察基础是否扎实。携程的业务链路——从用户搜索机票酒店、到下订单、支付、出票/确认、售后——这条链路对后端工程师的要求是数据库事务要懂缓存要懂消息队列要懂接口设计要懂。所以选择题考来考去基本就是围绕这些基础知识点打转。谁基础扎得深谁在这块就能拿快分。算法编程题是考察代码实现能力。不过说实话和字节跳动的笔试题比起来携程的算法题更“工程化”它不喜欢出那种特别绕的纯技巧题反而更喜欢出“实际业务场景简化后的算法模型”。比如我当时遇到的第二道题本质上就是个带约束的路径规划问题让我觉得它是在模拟“用户从A城市到B城市中间要不要经停、怎么选中转方案”这种真实场景。最后的业务场景设计题算是携程笔试里最有“携程味道”的一题。它不给标准答案考察的是你的技术视野。我当时看到那道题的第一反应是这玩意儿光靠背题肯定搞不定必须对系统设计、业务容灾、数据一致性这些真问题有概念。1.3 这批笔试的竞争压力参考2023年春招整体是“僧多粥少”的状态携程作为OTA头部大厂技术通用岗的投递量非常大。据我在牛客和脉脉上看到的讨论这批笔试大概是“海笔”——也就是简历初筛通过后大面积发笔试邀请然后通过笔试再筛掉一大半人。所以不要觉得收到了笔试邀请就等于稳了笔试的淘汰率通常不低特别是编程题和业务题如果分数很低后面连面试机会都可能拿不到。但好消息是携程笔试的分数不是唯一的筛选标准。它对学历没有那么苛刻更看重的是综合能力。也就是说哪怕你学校一般只要笔试表现足够好尤其是业务场景题写出了亮点还是有很大机会进入面试环节的。2. 核心题型逐项拆解与解题策略2.1 专业知识选择题覆盖范围与高频考点这部分是最容易拿分也最容易因为粗心丢分的。我当时遇到的题目覆盖了这样几个经典板块数据结构二叉树遍历、栈和队列的应用、哈希冲突的解决办法、排序算法的时间复杂度对比。这些都属于“八股文”范畴只要基础课学过基本都能答个八九不离十。计算机网络HTTP和HTTPS的区别、TCP三次握手、DNS解析过程、常见状态码含义。携程毕竟是线上业务公司对HTTP这块特别看重我记得有好几道题都围绕“用户在App上打开携程首页背后经历了哪些网络请求”来出。操作系统进程与线程的区别、死锁的必要条件、虚拟内存的作用。数据库索引为什么用B树、事务的ACID特性、数据库的隔离级别。多选题是重灾区选多选少都不得分。所以遇到多选的时候我的策略是“先把确定的选上不确定的坚决不选”哪怕少拿一点分也好过直接送掉整道题。2.2 逻辑推理题难得一见的行测混搭说实话技术岗笔试里出现逻辑推理题很多同学是措手不及的。我在考场上就看到有人吐槽说“这是要转行考公务员吗”。但后来仔细想想这种题考的是你在面对一堆数据、一堆传闻的时候能不能快速理清相互关系。比如有一道题特别典型背景大概是“产品经理提了一个需求但需求描述有歧义给你四个选项让你判断哪个选项一定能推出产品经理的真实意图”。这种题需要你先把逻辑链画出来再逐个代入选项验证。这类题没有太多捷径主要靠刷题找感觉。我当时是提前两周每天晚上拿“公务员行测判断推理”的题库来练手不求全对只求在60秒内能判断出题型并做出选择。事实证明这个策略非常有效至少保证了我在逻辑推理环节没有因为题型陌生而浪费太多时间。2.3 算法编程题两题定胜负的关键环节编程题是整场笔试里最硬核的部分。携程的笔试平台支持Java、C、Python等主流语言建议用自己最熟练的语言不要在考场上尝试不熟悉的新语言。我当时用的Java因为携程的技术栈很大一部分是Java体系用Java写至少心理上觉得“更对口”。第一道题是比较经典的“数组题”给定一个整数数组以及一个目标值要求找到数组中有多少个子数组的和等于目标值。它其实考察的是前缀和加上哈希表优化的思路。直接暴力枚举所有子数组的话时间复杂度是O(n^2)遇到大数组直接超时。我当时用了“前缀和数组HashMap”的套路先把前缀和算出来然后遍历过程中用map记录之前出现过的前缀和次数这样一次遍历就能得到答案时间复杂度直接降到O(n)。第二道题稍微复杂一些背景忘了但本质上是一道“带约束的最短路径搜索”能用BFS或者带剪枝的DFS来做。我当时用的BFS因为这种题只要状态定义得清楚BFS最稳妥。写的时候我特意注意了几个细节起点和终点重复判断、访问数组的初始化、路径长度累加的边界条件。这些细节其实在笔试中特别容易出问题很多人不是不会做而是写着写着边界条件出错导致只过了一部分测试用例。2.4 业务场景设计题真正的拉分项这部分我必须专门拿出来写因为它跟普通的技术面完全不同也跟常见的LeetCode刷题完全无关。第四批的业务场景题大概是这个方向的题目描述了一个票务或酒店预订场景中的真实业务痛点然后要求你给出技术设计方案。我当时遇到的问题是跟“机票价格缓存”相关的某机票产品在促销期间流量暴涨但是价格数据又需要实时准确问你如何设计一套高并发下的机票价格查询系统在保证数据不过期的前提下降低数据库压力。我当时的分层设计思路是这样的业务层前置缓存把高频查询的航线价格放在Redis里设置一个合理的过期时间比如30秒过期后回源数据库查询并更新缓存这样能挡住大部分读请求。数据库读写分离主库负责价格更新从库负责价格读取降低单库压力。消息队列削峰如果短时间内的价格更新量太大就直接用MQ削峰不能把突发流量都压到数据库连接池上。兜底降级万一Redis集群挂了要有降级开关保证用户能看到上一次缓存的过期价格而不是直接白屏或报错。这题没有标准答案但评分点大概会落在能不能理解高并发读多写少场景下的技术选型、有没有考虑到缓存一致性、数据库压力、系统可用性和降级方案等几个维度。我在回答里额外加了一个“针对极端热点数据”的细节比如某条热门航线在促销开始瞬间的并发查询量可能是平时的几十倍这种热点数据不能只靠通用缓存要有单独的本地缓存层比如Caffeine做极速响应防止打爆Redis。我觉得这个点应该是加分的因为它说明我不只是在背方案而是真的考虑过极端流量下的工程细节。3. 实战过程复盘我的答题时间分配与现场情况3.1 考前准备阶段说实话考前我并没有专门去做“携程往年笔试真题”因为这种东西很少流出来。市面上的题库大多是网友回忆版真正的题目几乎见不到。我当时的策略是把LeetCode Hot 100里的数组、字符串、二分、搜索、动态规划类题目全部过了一遍。把牛客网上的Java后端笔试题库刷了一遍重点是计算机网络和数据库部分。看了几篇携程技术团队发表在公众号上的技术文章重点看他们如何描述自己的业务场景和技术架构比如“缓存设计”“高并发架构”“微服务拆分”这些关键词。现在复盘最后一步对我帮助最大。因为业务场景题其实考的不是你背了多少“面经”而是你能否快速理解一个业务场景并给出符合业界主流实践的技术方案。读了那些技术文章之后我对携程的技术语言体系有了基本认知知道他们在什么场景下会用什么组件写出来的方案不会太“外行”。3.2 考场上的真实时间线我是晚上7点参加的在线笔试平台有摄像头监控要求全屏答题不能切屏。这些流程很常规但我要特别提醒一下一定要提前测试好摄像头和网络我当时室友在隔壁屋看直播差点给我卡掉线后来还是临时把网络切成了手机热点才稳定下来。笔试过程中建议找个安静的环境避免被打断。整个时间线大概是这样的前10分钟浏览全卷先做掉20道专业知识选择题会就选不会就标记不恋战。接下来的20分钟做逻辑推理题正常速度推进。再接下来的40分钟死磕编程题第一题用时15分钟第二题用了大概25分钟。最后剩下的时间全部扑在业务场景题上大概写了500多字的方案描述。这里我想说说一个很多人会忽略的问题很多人习惯按顺序做题但笔试题目往往不是按难度递增排列的。我看到不少人在专业知识选择题上反复纠结结果后面编程题时间不够用这就很可惜。我的习惯是先做选择题因为选择题如果不确定蒙一个还有概率得分但编程题如果时间不够可能连一分都拿不到。3.3 编程题的代码实现细节这里我给两道编程题做一个“回忆版”的代码思路还原不是原题但题型和核心考点非常接近可以参考着练习。第一题是子数组求和问题我贴一段核心代码辅助说明public int subarraySum(int[] nums, int k) { MapInteger, Integer prefixSumMap new HashMap(); prefixSumMap.put(0, 1); int sum 0; int count 0; for (int num : nums) { sum num; if (prefixSumMap.containsKey(sum - k)) { count prefixSumMap.get(sum - k); } prefixSumMap.put(sum, prefixSumMap.getOrDefault(sum, 0) 1); } return count; }这段代码的思路就是用前缀和数组把问题转化为“找两个前缀和之差等于k的索引对”。用哈希表记录每个前缀和出现的次数遍历一次即可完成。核心点是“前缀和之差等于k”以及“哈希表存的是前缀和出现的次数而不是索引列表”。我当时第一次写的时候存的是索引列表但后来发现存次数就够用了还能省空间。这些小优化在写代码的时候不明显但很影响最终运行时长。第二道题我记得当时写的是BFS。因为笔试时写的代码没有保存下来这里我就不贴完整代码了只画一下状态定义的思路状态当前节点, 当前已使用的某种资源数 转换从当前节点可以用某种代价移动到邻居节点 目标到达终点时的最小代价这个题型的实质是“状态空间搜索”。如果只是普通的最短路用Dijkstra你也不会觉得难但加了“资源约束”之后状态的维度变高了需要把“资源数”也作为一个维度加入访问标记数组里。很多人会忘记这一点导致陷入无限循环或答案错误。我在考场上也差点掉这个坑后来画了个简单的状态转移图才想明白。3.4 业务场景题的成文思路还原业务场景题我写了大概五百字结构大概是“一句话点明业务痛点 - 给出整体技术架构 - 分模块描述 - 强调关键细节”。这里我也给大家还原一下我当时的技术方案骨架“本方案的核心是高并发读多写少场景下通过“Redis缓存 数据库读写分离 本地进程缓存”三层架构来支撑流量洪峰通过消息队列异步化价格更新保证最终一致性。”“第一层Nginx负载均衡层负责流量分发和静态资源处理价格查询动态请求转发到应用层。”“第二层应用层集群使用无状态服务横向扩容即可应对流量增长应用内使用Caffeine作为本地缓存有效缓解Redis压力。”“第三层Redis缓存集群存储热门航线价格数据使用主从集群模式保证高可用主节点负责写入从节点负责读取。”“第四层MySQL数据库层采用分库分表架构将热点航线价格数据按航线哈希分片降低单表数据量。”“数据更新链路价格变更服务 - 更新DB - 发送MQ消息 - 缓存更新服务消费消息 - 更新Redis并设置过期时间 - 删除本地缓存。”“降级方案当Redis不可用时开启本地缓存降级模式返回上一次缓存的价格数据并在响应头标记“数据延迟”保证用户体验不中断。”这个方案我不敢说有多完美但至少逻辑自洽、结构清晰该覆盖的点都覆盖到了。如果你现在准备笔试我强烈建议去把“缓存穿透、缓存击穿、缓存雪崩”这三个老八股吃透因为各种业务场景题最后基本都会落到缓存上。4. 常见问题与避坑指南4.1 时间不够用怎么办这是很多人加我微信问得最多的问题。实话实说携程笔试120分钟内容量并不算少尤其是编程题如果卡住了非常容易影响后面的业务题。我自己的经验是编程题最多40分钟如果超过这个时间还没写出来先写一个暴力解法保底把部分测试用例过了再说。总分永远比单题满分重要。还有一点业务场景题是纯文字描述不考代码。哪怕你不确定你自己的方案是不是最优也一定要写满。写得太少会给面试官一种“这人不擅长系统设计”的印象。哪怕只是把常见缓存、消息队列、读写分离这些概念套进去也比交白卷好得多。4.2 笔试平台操作细节编程题支持本地IDE调试吗这个问题有很多人问。我当时用的平台是支持在线调试的但不支持你跳出浏览器使用本地IDE。所以你在练习的时候一定要逼自己习惯在网页编辑器里写代码不然考场上会非常别扭。还有一个非常影响心态的问题有的同学不知道可以在线“运行”测试用例导致代码写完了也不确定能不能过。携程笔试平台的编程题一般有几个可见的测试用例写完代码之后一定要先点“运行”确认样例通过了再点“提交”。这个步骤能帮你发现很多低级错误比如变量名写错、数组越界、输入格式读取错误等。4.3 心态管理笔试过程中肯定会遇到不会的题我当时在逻辑推理部分也有一两道完全没思路的。我的建议是该放弃就放弃直接蒙一个然后把时间留给能拿分的地方。不要因为一道题卡住就反复纠结最后把整个节奏打乱了。另外考前一定要去牛客、小红书或者知乎搜一下最近一批的笔试经验。虽然题目每次都在变但题型分布和考察风格是相对稳定的提前知道会考察哪些部分心里就不会慌。5. 部分题目的复盘与延伸思考5.1 一道关于“航班中转方案”的算法题第二道算法题给我的印象特别深因为它一看就是携程业务里“机票中转推荐”的简化模型。题目大意是这样的给定若干个城市之间的航班每段航班有固定的出发到达时间和中转最短时间要求要求找到从出发城市到目的城市耗时最短的航线组合。这道题往深了想其实是一个“时间依赖的最短路问题”在真实的携程系统里需要考虑的因素比笔试版本复杂得多不只是最短时间还有价格、航司偏好、中转机场便利度、行李是否直挂、退改签政策等。但在笔试中它一般只考其中一个维度的最优化比如最短总耗时或最少中转次数。我当时用了BFS因为“最少中转次数”是BFS的天然优势。但如果题目改成“总耗时最短”并且加入了时间窗约束就得用Dijkstra或带优先队列的BFS了。这里提醒一下写BFS的时候如果你把“访问过就不能再访问”当成铁律可能会漏掉最优解。因为有些场景下同样的节点可以用更短的时间再次到达所以状态不只是“城市”本身而是“城市时间”。5.2 关于“防止超卖”的业务题延伸我听说有些批次的业务题会考到“酒店预订超卖”的问题这其实也是一个非常经典的场景。大致就是在用户A和用户B同时预订同一间房的时候如何保证只有一个用户能成功下单另一个用户看到“已被预订”。从技术角度来说这涉及到数据库的悲观锁/乐观锁、Redis的分布式锁、以及订单状态机的设计等。我当时在准备时专门把超卖问题梳理了一下方案一数据库加悲观锁使用SELECT ... FOR UPDATE锁定房型记录简单直接但并发高时锁竞争严重。方案二使用乐观锁在更新时检查版本号如果版本号变了则重试或返回失败。方案三用Redis做分布式锁先到先得锁住房型ID获取到锁的用户才能进入下单流程。方案四用Redis的原子扣减库存操作比如DECR并配合订单回滚机制保证最终一致性。如果笔试真的遇到了这类题我觉得最优解不是只写一种方案而是要对比几种方案的优缺点然后说明你在什么场景下选什么方案。这能体现你不仅是“会背八股”而是真的理解技术选型背后的交易成本。我当时的策略是“数据库悲观锁兜底 Redis预扣库存 消息队列最终一致性”兼顾了并发性能和数据的最终可靠。5.3 携程技术笔试风格总结整体来看携程笔试与其他大厂相比有一个显著不同它会拿出一定比例的分值去考察你纯技术以外的“逻辑推理能力”和“业务理解能力”。这两个能力不是靠刷题就能产生的更多靠平时积累和对业务的思考。所以如果你还有一段时间才笔试建议除了刷算法题之外多去看看携程技术团队的文章多思考一下“如果你是携程机票业务的后端架构师你会怎么做”。这种思维训练远比背一百道题有用。6. 实用工具与准备路线6.1 笔试环境与语言选型笔试推荐只用一种编程语言学精比学多更重要。虽然C和Python在算法竞赛中很常见但在携程这类公司里Java后端的岗位量是巨大的。如果岗位描述是“后端开发”建议主攻Java如果是“算法工程师”可以pick Python如果是“客户端开发”那就看是Android还是iOS方向来选。我自己用的Java因为笔试平台对Java的支持很完善。但Java写算法题有个小劣势代码量偏大。比如你要用PriorityQueue得new一个比较器不像Python里几行就搞定。如果你Python很熟其实也可以选Python但前提是“很熟”而不是“能用”。6.2 刷题资源推荐我当时刷题的优先级是这样的LeetCode Hot 100这个必刷。携程的算法题难度大概在Hot 100中等题的水平把Hot 100刷熟笔试的算法题基本不会慌。牛客网历年名企真题牛客的大厂笔试题库可以拿来做模拟训练不用太在意是不是携程原题主要是练习在有限时间内应对陌生题目的能力。CodeTop一个可以查看各大厂高频考题的网站对于了解主流考点非常有帮助。每天刷题不用贪多我一般是三道题一道Hard或两道Medium。周末会做一次整套的模拟笔试计时加摄像头完全仿真考试环境。这种做法非常有助于适应真实笔试的紧张感。6.3 持续复盘的重要性每次模拟笔试后一定要花时间复盘错题。我有个习惯把每道错题的问题类型、错误原因、正确思路写在一个表里每周翻一次。这样到临近笔试的时候你的弱点其实已经一点点被补上了。我这里整理一个简化版的自查表供参考是否因为读题不仔细导致理解错题意是否是因为某个数据结构不熟练导致代码写不出来是否是因为时间分配不合理导致后面题目没时间写是否是因为边界条件考虑不周导致测试用例没过每次模拟后都过一遍这张表你的稳定程度会肉眼可见地提升。7. 写在最后我对这场笔试的几个体会写到这里核心内容差不多讲完了。最后忍不住想分享三点个人感受。第一不要太迷信“押题”。网上确实有一些所谓的“携程历年笔试真题”但来源不明、年份不明参考价值极其有限。真正可靠的方式还是提升通用能力——算法、系统设计、业务思考。这些能力到了面试环节也一样管用。第二业务场景题不是“写论文”不需要用一堆高大上的术语堆砌。我记得我当时写方案时面试官后来在面试中提到“笔试中能主动提到本地缓存这个点的人不多”。这说明什么说明面试官其实是在找一个“愿意多想一步”的候选人。单纯写“用Redis缓存”谁都会但“Redis的key要如何设计才能避免热点问题”“缓存穿透如何用布隆过滤器解决”这些细节才真正体现思考深度。第三也是我最想说的笔试不仅是一次评测也是一个了解这家公司的窗口。借由准备“携程春招笔试”你其实会顺带了解在线旅游行业的技术挑战高并发、价格一致性、库存防超卖、搜索推荐、风控……这些业务问题比单纯刷算法题有意思得多也值得任何一个想做技术的同学去花时间琢磨。如果你能在这个过程中真正对某个业务问题产生兴趣那这场笔试的收获就远不止一个offer了。