去年差不多这个时候，我参加了2023年携程春招技术通用岗的第三批笔试。当时正在春招海投阶段，笔试做了不少，说实话携程这场给我的印象还挺深——不是因为它题目特别难，而是题型结构、平台交互和出题思路都挺有代表性的，和许多大厂的在线笔试一脉相承，同时又带着明显的业务特色。后来我把这场笔试的过程和题目复盘整理成笔记，最近翻出来发现很多内容对准备校招的朋友依然有参考价值，就想着把它展开写成一篇文章。
这篇文章会从笔试流程、题型分布、编程题逐题拆解、考点延伸、踩坑记录几个角度来讲，不光是告诉你“考了什么”，更想帮你理解“为什么要这样考”“怎么准备更有效”。如果你正在准备春招、或者接下来要面对在线笔试，这篇文章应该能帮你少走一些弯路。
1. 笔试整体情况与前期准备
1.1 批次安排与笔试基本流程
携程春招技术岗分了多个批次，第三批属于比较靠后的批次。这里先说明一下，春招笔试和技术岗的“通用岗”定位直接挂钩——它不像算法工程师或后端某个专项岗位那样要求极高深的特定方向知识，而是面向更广泛的技术候选人，考查的是计算机基础功底、编码能力、逻辑思维和问题分析能力。它更像是一次“技术能力扫描”，面试官通过这份结果来判断你值不值得进入后续的面试环节。
笔试形式是在线笔试，使用赛码网平台，双机位监控，需要提前准备好电脑、摄像头和稳定的网络。整个笔试流程包括几个环节：登录验证、身份确认、阅读考试须知、开始答题。我当时提前半小时进入系统，测试了摄像头和麦克风，在赛码网平台上完成了一次模拟登录，确认代码编辑器可以正常工作。这里给第一次用赛码网的朋友提个醒：这个平台和部分在线笔试系统不太一样，交卷后不能修改答案，编程题的输入输出格式也需要自己处理，后面我会展开说具体细节。
1.2 通用技术岗的考察范围判断
用一句话概括通用技术岗笔试的考察逻辑：基础不丢分，代码要能跑，思路要清晰。它不会像算法岗那样出现大段的数学推导和模型设计题，也不会像专门的前后端岗位那样考非常深的知识细节，而是通过选择题和编程题的组合来评估一个候补工程师的综合技术素质。
从我这次实际的体验来看，题型分为两部分——选择题和编程题。选择题覆盖了Java基础、计算机网络、操作系统、数据库、设计模式等计算机专业核心课程内容；编程题则是三道不同难度梯度的算法题，需要在赛码网的在线编辑器里完成代码编写和提交。整个笔试时长大概是选择题加编程题总共两小时出头，时间上是比较紧张的，后面我会专门分析做题节奏的问题。
1.3 赛码网平台的特点和应对策略
赛码网是很多大厂校招用的在线笔试平台，它的特点值得单独说一下。首先是代码提交方式，编程题有“核心代码模式”和“ACM模式”两种，核心代码模式是给你一个类名和方法签名，你只需要实现方法体；ACM模式则需要自己处理全部输入输出。我当时遇到的是核心代码模式为主，但你也得做好遇到ACM模式的准备，所以提前熟悉一下标准输入输出的写法是有必要的。
其次是平台的代码编辑器，自动补全和语法提示都比较弱，基本等于一个带高亮的记事本，而且在线编辑器不能使用本地IDE的快捷键。这个细节在平时看起来没什么，但在笔试的高压环境下就会放大——如果你重度依赖IDE的自动补全，上了考场写代码的流畅度会明显下降。我的建议是笔试前两周就开始用这种弱提示的环境刷题，让自己习惯脱离自动补全来编码。
2. 题型结构与分值分布复盘
2.1 选择题考察模块分析
选择题是这场笔试的第一部分，题量大约在二十道上下，每道题的难度适中，但覆盖面很广。我根据回忆把考点梳理成了几个模块，整理成表格方便参考：
| 考察模块 | 具体考点 | 出现频率 | 建议复习优先级 |
|---|---|---|---|
| Java基础 | 集合类源码原理、HashMap扩容、异常机制、泛型 | 高 | 高 |
| 并发编程 | synchronized与Lock区别、线程池参数、volatile语义 | 中 | 高 |
| 计算机网络 | TCP三次握手四次挥手、HTTP状态码含义、DNS解析过程 | 中 | 中 |
| 操作系统 | 进程线程区别、死锁条件、页面置换算法 | 中 | 中 |
| 数据库 | 索引数据结构、事务ACID、隔离级别、MVCC | 中 | 中 |
| 设计模式 | 单例模式手写思路、工厂模式应用场景 | 低 | 中 |
这里有一个值得注意的信号：Java基础出现的频率最高，这和携程的技术栈构成有关。携程的核心业务系统大量使用Java，所以通用技术岗的候选人对Java体系的掌握程度自然会被重点考察。如果你是主要使用C++或Python的候选人，建议在笔试前把Java的语言特性和常用集合类源码过一遍，性价比很高。
2.2 编程题难度梯度设计
三道编程题的难度有清晰的梯度，这个梯度设计其实反映了出题人的良苦用心——它不只是为了区分你会不会写代码，而是在有限时间内考察你的代码基本功、算法思维和问题分解能力。
第一道题偏简单，考查的是基本数据结构的应用，一般十分钟内可以解决，主要为了让大多数候选人能拿到基础分。第二道题中等难度，通常需要结合排序和贪心思想，考查的是分析问题后选择合适策略的能力。第三道题偏难，基本是经典的动态规划或更复杂的算法思路，用来筛选真正有算法功底、能在压力下保持思路清晰的候选人。
三道题的分数比重也不同，从我的经验看，编程题得分在整场笔试中的权重远高于选择题，因为选择题的区分度有限，而编程题能直接反映一个人的实际编码水平。所以我的策略非常明确：保证第一题和选择题的正确率，尽力拿第二题的分数，第三题即使不能完美通过也要把暴力解写出来，争取部分测试用例通过。
3. 编程题逐题拆解与代码实现
3.1 第一题：基于哈希表的字符串处理
这道题我记得很清楚，题目大意是：给定一系列旅行记录，每条记录包含一个出发城市名和一个到达城市名，格式为“城市A 城市B”，表示一段从A到B的行程。这些记录可以串联成一条完整的旅行路线，不会存在环。要求输出完整的路线，即从起点城市到终点城市，中间所有城市按出现顺序输出。
这道题本质上是寻找链表结构的起点并按序遍历。每个城市可以看作一个节点，每条记录就是一条有向边。核心思路是用两个HashSet分别记录所有的出点和入点，再通过HashMap建立城市之间的映射关系。
我用Java实现了这个解法：
import java.util.*; public class TravelRoute { public List<String> findRoute(String[][] records) { // 出点集合和入点集合 Set<String> startSet = new HashSet<>(); Set<String> endSet = new HashSet<>(); Map<String, String> nextMap = new HashMap<>(); for (String[] record : records) { String from = record[0]; String to = record[1]; startSet.add(from); endSet.add(to); nextMap.put(from, to); } // 起点是不在任何入点集合中的城市 String start = ""; for (String city : startSet) { if (!endSet.contains(city)) { start = city; break; } } // 沿路构建完整路线 List<String> route = new ArrayList<>(); String cur = start; while (cur != null) { route.add(cur); cur = nextMap.get(cur); } return route; } }这个解法的复杂度是O(N)，其中N是记录条数，一次遍历建立映射，再一次遍历构建路线，时间和空间上都是最优的。这道题作为开胃菜，考的是哈希表的基础应用和用集合来寻找起点的思维转换。很多人第一反应是用两层循环去匹配，那样也能做，但复杂度会退化到O(N^2)。笔试中这种代码能跑通，但用哈希表显然是更好的答案。
这道题给我的启发是，笔试中的简单题也千万不要掉以轻心，有些候选人因为过于追求秒杀反而会漏掉边界条件。比如这里如果输入只有一条记录（即只有两个城市），你的代码必须能正确处理；如果起点城市在记录中出现了多次但都是作为出发地，也要保证只需要找一次。
3.2 第二题：排序加贪心的经典组合题
第二题的内容是关于优惠券的最优分配。题目大概是这样的：携程平台上有M张满减优惠券，每张券有两个属性——满减门槛（订单金额达到多少可用）和减免金额。现在有N个订单，每个订单只能用一张券，一个订单金额必须大于等于该券的门槛才能使用，问如何分配优惠券，使得用户获得的减免总额最大。
这个题一看就是贪心，但贪心的顺序有讲究。正确的思路是：把订单金额从小到大排序，把优惠券按门槛从小到大排序，然后逐个处理每个订单。在处理某个订单时，把所有门槛小于等于这个订单金额的优惠券加入一个优先队列（最大堆），堆顶是减免金额最大的券，直接使用它。这样可以保证每一张券都用在它“能用的订单”中，并且每次都选择减免力度最大的那一个。
这个解法的时间复杂度是O((M+N) log M)，因为每个优惠券最多入堆一次、出堆一次。核心代码逻辑如下：
import java.util.*; public class CouponAllocation { // orders: 订单金额数组, threshold: 优惠券门槛, discount: 优惠券减免金额 public long maxDiscount(int[] orders, int[] threshold, int[] discount) { Arrays.sort(orders); // 将优惠券按门槛排序，用下标关联threshold和discount Integer[] couponIdx = new Integer[threshold.length]; for (int i = 0; i < couponIdx.length; i++) { couponIdx[i] = i; } Arrays.sort(couponIdx, (a, b) -> threshold[a] - threshold[b]); PriorityQueue<Integer> heap = new PriorityQueue<>((a, b) -> discount[b] - discount[a]); long total = 0; int couponPtr = 0; for (int order : orders) { // 把当前订单可用的优惠券全部入堆 while (couponPtr < couponIdx.length && threshold[couponIdx[couponPtr]] <= order) { heap.offer(couponIdx[couponPtr]); couponPtr++; } // 取减免金额最大的一张 if (!heap.isEmpty()) { total += discount[heap.poll()]; } } return total; } }这道题有相当一部分人会陷入一个误区：直接计算每个订单独立的“最优券”然后分配。这样会忽略一个关键点——一张减免力度最大的券如果被一个低金额订单用掉了，后面高金额订单可能就无券可用了。而正确做法是让“高门槛的券”尽可能匹配“高金额的订单”，所以在使用优先队列按订单从小到大逐个匹配时，我们实际上是在做一个全局最优的调配。
笔试的时候我是先花了大约三分钟分析思路，确认贪心策略的正确性后，再用大概十分钟完成编码。给一个经验性的建议：遇到这种资源分配类的题目，优先思考“是否存在贪心策略”，如果能在草稿纸上举一两个反例都找不到漏洞，大概率贪心方向是对的。如果你对自己的证明能力没那么自信，也可以用暴力枚举来验证小规模数据的正确性，笔试中时间允许的话这是一个很实用的手段。
3.3 第三题：动态规划压轴题
第三题是一道动态规划题，背景是酒店连续N天的房价，要求选择一个子序列进行投资组合最优值的模拟。因为时间太久，具体的约束我记得不是特别清楚了，但题目本质和经典的“打家劫舍”非常像：不能选择相邻的两天，目标是让最终收益最大化。
我当时很快识别出这是一维DP。定义dp[i]为前i天能获得的最大收益，则有状态转移方程：
dp[i] = max(dp[i - 1], dp[i - 2] + price[i])其中dp[i - 1]表示第i天不选，dp[i - 2] + price[i]表示第i天选并跳过第i - 1天。只需要滚动两个变量来优化空间，代码如下：
public class HotelProfit { public long maxProfit(int[] prices) { int n = prices.length; if (n == 0) return 0; if (n == 1) return Math.max(0, prices[0]); long prev2 = 0; // dp[i-2] long prev1 = Math.max(0, prices[0]); // dp[i-1] for (int i = 1; i < n; i++) { long cur = Math.max(prev1, prev2 + prices[i]); prev2 = prev1; prev1 = cur; } return prev1; } }这道题真正的难点并不在于状态转移本身，而在于你在考场上能不能快速识别出这个模型。很多人被题目那一大段业务背景文字绕晕了，忽略了“相邻不能同时选”这个关键条件，从而绕了一大圈去做背包、贪心等方向，浪费时间也没有得到正确答案。所以在笔试和面试中，读题时一定要先画核心约束，从背景中剥离出数学模型，再去想算法。
如果第三题你能在半小时内写出正确代码，说明你的基础算法功底已经超越了大部分候选人。即使写不出来，也建议把状态定义和转移方程写在注释里，至少向阅卷方展示你的思路比空着要好。
4. 选择题考点延伸与理论基础夯实
4.1 Java基础与并发编程考点
Java基础是选择题的稳定输出大头，尤其是集合类的底层实现细节。HashMap的扩容机制、JDK 1.8中链表转红黑树的阈值、ConcurrentHashMap如何保证线程安全，这些知识点我在考前特意再过了一遍，因为它们是Java面试题库中出现频率最高的内容。
并发编程部分考了synchronized和ReentrantLock的区别、ThreadPoolExecutor的核心参数含义、volatile关键字的可见性和有序性。这里很多人的误区是死记概念，没有真正理解“锁升级过程”和“AQS原理”。我的建议是结合源码去复习：不看源码光背结论，碰到选择题换个问法就容易错。比如synchronized在JDK 1.6之后引入了偏向锁、轻量级锁、重量级锁的升级路径，这种题如果只看过八股文很容易踩坑。
为什么企业笔试喜欢考这些？因为它们在日常开发中真的无处不在。携程这种体量的系统，高并发场景是常态，候选人是否理解并发编程不是解题层面的问题，而是能不能胜任真实项目的底线要求。所以准备笔试时不能用“过一遍”的心态来对待并发，最好是结合线上问题排查的案例去理解。
4.2 计算机网络与操作系统高频题
计算机网络这块，TCP握手、HTTPS建立流程、HTTP状态码语义这几类题目基本是标配。有一道题我印象很深，题目给出几个HTTP状态码，要求判断哪些属于重定向类别。这种题失分很不值得，301、302、303、307、308的含义平时写接口联调都会遇到，稍微整理一下就能记住。
操作系统考察的重点集中在进程与线程、死锁、虚拟内存和页面置换。这里有一个容易忽略的知识点：进程调度算法的区别，尤其是CFS调度器的原理。操作系统内容多而杂，但笔试涉及的都是概念性质的选择题，不建议投入过多时间做特别偏向内核的深入复习，把核心概念和经典算法掌握好就足够拿分了。
数据库模块也很关键。索引为什么用B+树而不用B树或红黑树这类经典问题的出现频率很高，事务的四种隔离级别分别解决什么问题、会产生什么并发异常也是常考内容。我复习的时候会把每个考点和一个小的记忆锚点联系起来，比如提到MVCC就想到版本链、ReadView的生成时机；提到索引就想到B+树的非叶子节点不存储数据这一设计。用这种“场景化记忆”的方式比罗列知识点高效得多。
4.3 设计模式与场景分析题
设计模式在选择题中占比相对少，但有一类题目需要引起重视——给出一个场景，要求你选择最合适的设计模式。这种题不是考你23种模式的名字背得多熟，而是考察你是否理解每种模式解决的问题边界。
举个例子：如果有一个流程需要固定的算法骨架，但其中某些步骤的具体实现可以在子类中变化，这种情况通常会考虑模板方法模式；如果需要在运行时匹配一组可以互换的算法，那更适合用策略模式。这些区分点光看书是体会不到的，最好通过一些实际项目或者开源框架的源码来理解。我记得当时复习设计模式时看了Spring源码中bean的创建流程，对模板方法模式和工厂模式的理解一下子就通透了。
选择题部分我个人觉得拼的不是“广度”，而是“基础扎实程度”。有经验的面试官也很清楚，选择题并不能说明一个候选人的全部实力，但它能快速筛选出基础知识漏洞太大的人。所以准备选择题的时候不要想着押题，踏踏实实把核心概念吃透才是正路。
5. 实战踩坑记录与笔试避坑指南
5.1 赛码网提交的痛点总结
赛码网平台有几个和普通本地IDE明显不同的地方，如果不提前适应，考试中很容易手忙脚乱。第一个痛点是核心代码模式下不需要去处理输入输出，但你必须严格遵守题目给出的类名、方法签名和返回值类型——要求你返回int你非要返回long可能直接编译失败，要求类名为Solution你取名别的也过不了编译。考场上因为这种低级错误导致零分的案例不少见。
第二个痛点是代码的调试体验。赛码网的编辑器不像本地IDE可以打断点调试，报错信息也相对简单。这就要求你在提交通用之前，自己在脑子里多跑几个用例，尤其是边界情况——数组为空、长度为1、包含负数、数字溢出等。我当时的习惯是先在代码里加上防御性判断，再花一两分钟在草稿纸上手推一个最小样例，这样可以有效避免低级错误。
第三个痛点是提交机会。部分题目有提交次数限制，不是可以无限次编译运行。我参加的那场笔试编程题提交是计次数的，你可能因为某个隐藏用例没有通过而反复提交，但如果次数用完了就无法再提交了。这种设计说到底就是在考验你的调试能力和一次性正确率，所以在写代码的时候一定要想清楚再动手，不要边想边写。
5.2 在线笔试的节奏控制与心态管理
在线笔试和线下笔试最大的区别，就是没有监考老师提醒你时间，计时器就挂在屏幕角落，你很容易在某一题上沉浸太久。我给自己定的一个粗糙但是有效的时间分配方案是：选择题整体控制在30分钟以内，编程题第一题10分钟，第二题20分钟，第三题最多30分钟，剩下时间用于检查和调试。但如果你发现一道选择题纠结超过两分钟，建议先标记跳过，不要为了1分的题赔上后面10分的编程题时间。
心态方面，我想多说两句。春招笔试高频安排很密集，经常出现上午一场下午一场的情况，人很容易进入一种疲惫但焦虑的状态。我在那段时间总结出的一个经验是：不要因为某一场笔试感觉不理想就影响下一场。每场笔试结束后花15分钟快速记录题型和自己不会的知识点，然后立刻把注意力转到下一场。抱着“反正还有下一场”的心态去考，反而能降低紧张感，发挥更稳定。
5.3 从一场笔试反推面试准备方向
笔试结束后的复盘价值可能比那两小时本身更大。无论结果如何，我都会把笔试中遇到但没把握的题目整理进一个文档，按知识点分类标好。这一轮题目如果有印象深刻的考点，面试中被问到的概率非常高——因为同一批面试官出题思路是一脉相承的。
比如我整理下来的几个延伸方向是：HashMap的扩容为什么是2的幂次方、线程池的拒绝策略有哪些、事务隔离级别之间是怎么演进的、设计模式在Spring中的应用等。这些方向后来在携程面试中果然命中了一部分。这就说明，笔试不只是筛人工具，更是一个很好的面试准备清单。把笔试中暴露出来的薄弱点补齐，面试时的底气会完全不同。
6. 从笔试题目反推企业技术与业务侧重
6.1 题目背后透出的技术栈信号
如果把笔试的常考点拼在一起，可以大概看出携程这类在线旅游企业后端研发的技术栈框架。Java相关考察权重最高，不难推测核心业务系统以Java体系为主，SpringBoot、微服务、消息队列等是日常开发标配。计算机网络的高频出现说明业务对网络交互的稳定性、性能优化有很高的依赖，毕竟预订、支付、订单状态同步这些核心链路都建立在复杂的网络调用之上。
试题背景中也经常混入电商和旅游综合业务逻辑的变体，例如优惠券满减、行程串联、酒店预订等。这是大厂笔试非常典型的风格——用业务场景包装算法题。出题人不只是想让候选人解一道算法，而是在考察你有没有能力把一个模糊的实际问题抽象成清晰的数据结构和算法模型。这种能力在真实的工程实践中比单纯的刷题能力重要得多，因为日常项目中大量问题都不是现成的LeetCode原题，而是嵌套在业务规则里的变形题，你得自己完成从问题到模型的转化。
6.2 笔试成绩在招聘流程中的作用
很多候选人会有一种疑问：笔试成绩到底有多重要？以我自己的观察来看，笔试成绩决定了你是否能进入面试环节，而进入面试后，面试官手里会拿着一份笔试报告来作为交流的参考。如果你的编程题解法思路清晰、代码风格良好，面试官可能会就此展开追问；如果笔试中某一块正确率明显偏低，面试官也可能会针对性地考察你相关的基础知识。
所以不要把笔试当成一个孤立的“门槛事件”，把它当成一次和面试官隔空对话的机会更为恰当。你在代码中表现出的逻辑严谨性、边界敏感度和代码规范程度，都会通过笔试报告传达到面试官那里。这也是为什么我建议即使笔试时间再紧张，也要保持代码变量命名清晰、逻辑分层明确的原因——你写的每一行代码都可能是面试时的谈资。
6.3 面向校招的技术学习节奏建议
最后聊一下我在准备春招时的整体学习节奏，给还在备考的朋友们一个参考。提前三个月左右进入系统刷题阶段，每天保持2到3道题目的输出量，重点练习中等难度的题目，因为大厂笔试的重头戏通常在中档题。提前一个月开始穿插选择题的模块复习，按Java基础、计算机网络、操作系统、数据库、设计模式这样的顺序推进。考前两周切换到在线模拟环境，用赛码网或者其他类似的在线笔试平台做题，训练自己在无IDE辅助、无自动提示的弱环境下编码的能力。
我踩过最大的坑就是前期刷题时过于依赖本地IDE的自动补全和错误提示，到了线上笔试才发现代码能力打了折。编码能力是肌肉记忆，只有平时在“不依赖脚手架”的模式下写，上了考场才能把这种能力迁移过去。建议大家从第一天刷题开始就养成裸编码的习惯，最好用系统自带的文本编辑器或者在线答题环境来敲代码，这样做不仅笔试受益，面试时在白板上手写代码也能更加从容。
在模拟的时候还要注意严格限制时间，我会给自己设置45分钟一套编程题的时间窗口，宁可少做一道也要保证提交的代码能通过尽可能多的测试用例。这里有一个很多人忽略的技巧：如果一道题实在写不出最优解，也要把最朴素的暴力解法写上去，哪怕只通过一部分用例也能拿到部分分数，直接留空是最可惜的——这个道理，经历过笔试的人应该都能懂。
