1. 笔试整体结构与考察逻辑拆解1.1 技术通用岗笔试到底在筛什么人先说结论携程技术通用岗的笔试重点不是筛掉“不会写代码”的人而是筛掉“代码写得不够利索”的人。秋招笔试阶段说白了就是一道海选闸门几千人同时在线做同一套题如果题目太简单区分度不够后续面试官的压力会非常大。所以第四批笔试的难度设计整体是卡在“LeetCode中等题为主、少量困难题压轴”这个区间。我那时候拿到这套题的第一感受是题型结构非常稳定基本延续了前几批的套路——两个编程大题加一道场景设计题偶尔会穿插选择题或者SQL题。但第四批有个明显特征编程题的代码量偏大且边界条件藏得很深。也就是说题目本身的核心算法你或许能想到但要在有限时间内把代码写对、把所有坑填完这才是真正的考验。从岗位属性来看技术通用岗覆盖了后端、前端、客户端、测试、运维等多个方向笔试不可能针对某一个方向出太细的专业题所以它的考察重点落在了“通用基本功”上——数据结构、算法思维、代码规范、问题拆解能力。说白了它要看的是你这个人在工程和算法之间有没有平衡感。1.2 第四批区别于前几批的核心特征如果你去刷前几批的回忆题会发现第三批大量考察了贪心和二分答案而第四批有一个比较明显的变化动态规划的占比上来了而且不止一道。我当时做完之后跟几个一起投递的朋友对了下发现DP题至少出现了两到三道其中一道是二维状态转移另一道是带滚动数组优化的变体。另外一个特征是输入输出格式的设计更复杂了。有一道题的数据不是普通的整数数组而是类似“第一行两个整数n和m接下来n行每行若干数据且每组数据之间有空行”这种比较麻烦的格式。很多同学平时刷LeetCode习惯了封装的输入输出到了笔试环境用牛客网或者赛码网做这种OJ题字符串解析就卡了半天时间白白浪费掉。还有一点值得注意第四批的题目在“场景包装”上明显更贴近业务。有一道题描述的是航班接驳调度还有一道是酒店房价分组统计。这说明出题人有意在往业务场景上靠不是纯考算法而是希望你既能抽象出核心模型又能在代码里处理业务层面的约束条件。如果只会套模板遇到这种换皮题就会懵。2. 核心考点与高频题型专项拆解2.1 动态规划从二维DP到状态优化第四批笔试里让我印象最深的一道题是典型的二维DP但套了个很业务的外壳给定若干组订单数据每个订单有开始时间、结束时间和收益问如何选择订单使得总收益最大且时间不冲突。这个题初看像区间调度贪心但因为有收益权重贪心并不成立正确的解法是按结束时间排序后做DPdp[i]表示前i个订单能获得的最大收益转移时二分查找最后一个结束时间不大于当前订单开始时间的下标。这里有个很关键的细节很多人想当然地写了O(n^2)的转移结果数据范围一出来n是10的5次方直接超时。我在考场上第一反应也是先写O(n^2)的版本拿部分分然后马上意识到必须优化。二分查找是纯log(n)的开销加上排序的O(n log n)整体复杂度就能过。还有一道DP题考的是“最长有效括号”的变体需要在两种括号类型之间做匹配。这道题表面上是栈的题但实际上用DP更稳妥dp[i]表示以第i个字符结尾的最长有效括号长度转移时区分当前字符是左括号还是右括号以及前一个匹配位置是不是对应类型的左括号。这种题的坑在于“类型不同不能匹配”很多人只改了字符判断忘记了更新状态时也要同步判断。2.2 图论与搜索最短路和拓扑排序的常见变体第四批的图论题没有出裸模板题而是出了一个“带修复代价的最短路”问题图中有若干条边部分边处于损坏状态可以通过支付代价修复问从起点到终点的最小“时间修复代价”之和。这道题本质上是个分层图最短路把“修复了几条边”作为状态维度建图时每一层内部正常连边层与层之间通过修复代价跳跃。我当时的做法是用Dijkstra跑三层分层图因为修复代价的范围限制得比较小所以每一层直接开一个距离数组就行。核心的细节在于堆优化Dijkstra的写法要熟练否则调试起来非常痛苦。还有一点是图可能是稀疏的邻接表必须用vector数组而不是二维数组否则内存直接爆掉。拓扑排序的题则和字符串拼接相关给若干字符串片段问能否拼出一个满足某种偏序关系的序列。这题需要自己抽象出“字母之间的依赖关系”然后拓扑排序判环。很多同学容易忽略的是拓扑排序的结果不唯一题目如果要求字典序最小得用优先队列来实现。这个细节虽然小但确实能区分候选人的代码功底。2.3 数据结构并查集与线段树的实战场景笔试里有一道题是“动态连通性问题”不断往图中加边每次加边后询问两个点是否连通。这是并查集的经典应用但出题人加了个“在线查询”的约束所以必须实时维护。这道题本身不难但很多人因为前面时间花太多到这道题的时候心态已经崩了简单题也写崩了。并查集有几个代码层面的优化点需要刻进肌肉记忆路径压缩要写在find函数里按秩合并要维护一个size数组而不是rank数组因为实际工程中size更直观。笔试环境下不要追求花哨四个核心操作——初始化、find、union、判断——必须写得又快又对。线段树那道题出现在选做题里让我印象很深刻因为它考的是“区间加、区间求和”的懒标记模板。很多人背了模板但不知道为什么懒标记要这样设计到了笔试遇到变种题就挂了。实际上懒标记的核心思想是“延迟更新”把区间修改的代价摊到查询的时候再处理如果理解不了这一点一旦题目要你同时维护加法和赋值操作代码就会写得一团糟。3. 携程业务场景与系统设计题解析3.1 航班接驳调度题的抽象方法携程的核心业务是旅行服务所以场景题经常会从机票、酒店、火车票这些业务里抽素材。航班接驳调度题说的是若干架航班需要停靠有限数量的廊桥每个航班有到达时间和起飞时间廊桥在航班起飞后可以复用问最多能同时保障多少架航班使用廊桥。这题直观上像一个“会议室问题”给定开始时间和结束时间求最多能同时使用多少会议室。标准解法是贪心加最小堆先按开始时间排序遍历每个航班时把已经结束的航班从堆中弹出如果当前堆的大小等于廊桥数量就复用最早结束的那个廊桥。这里有个比较容易错的点复用时不仅要弹出堆顶还要把当前航班的结束时间重新入堆。这类场景题其实考察的不只是算法还有“能不能把业务语言翻译成技术语言”。在面试复盘时如果你能主动说出“这个问题本质上是一个区间调度问题和会议室II是同一类模型”面试官会对你有明显的好感。所以在笔试阶段想清楚这层抽象关系本身就是为后面的面试做准备。3.2 酒店房价分组统计题的细节处理另一道场景题考的是酒店房价的区间分组统计给定若干订单的价格和日期按周统计每个价格区间的订单量。题目本身不复杂用哈希表加差分数组就能做但琐碎的边界条件特别多。首先价格区间的划分是左闭右开还是左开右闭这直接影响了订单应该归属到哪个区间其次日期的跨度可能跨年周的划分不是简单的“7天一循环”而是要精确到周一到周日最后输出格式要求按日期升序输出还要处理某些周没有订单的情况。这些约束单独看都不难但它们集中出现在一道题里就是排查能力的大考验。我在做这道题时犯了个低级错误用mapint, long long存每周的统计结果但在日期转周编号时忘了处理跨年那一周的情况结果样例能过一提交就WA。后来检查发现跨年那周的两部分日期分别被算到了两个不同的周编号里这确实是一个隐蔽的坑。3.3 系统设计题高并发场景下的通用思路第四批的系统设计题是一道开放题设计一个酒店实时房态查询系统支持高并发读取要求保证数据最终一致并说明如果某个城市的查询量突然暴涨怎么做到快速扩容。这种题没有标准答案但考察的维度是固定的。一个好的回答框架是先分模块——存储层、缓存层、服务的无状态化设计、负载均衡策略、监控告警。我当时的思路是用Redis做热数据的缓存key设计成hotel_id datevalue存房型余量MySQL存全量数据通过binlog订阅同步到缓存查询服务只读缓存写操作走管理后台。这样设计的好处是读写分离彻底缓存命中率会比较高。扩容这块我提到了“服务无状态化自动伸缩组”的组合查询服务不保存任何本地状态所有的热点数据都在分布式缓存里。这样当流量暴涨时只需要在云厂商的控制台调整伸缩组的最小实例数或者接入弹性伸缩策略让新实例自动加入负载均衡池即可。数据库层面则考虑只读副本和分库分表避免单库压力过大。4. 备考实操30天冲刺路径与时间分配4.1 分阶段的刷题计划如果你决定参加技术通用岗笔试我建议倒推时间来准备。以30天为周期大致可以分成三个阶段第一阶段用来过基础数据结构和算法模板特别是动态规划和图论的标准写法第二阶段集中刷中等及以上难度的题目按题型分类而不是按题目编号顺序刷第三阶段是模拟笔试环境用牛客网或赛码网的OJ做整套真题模拟严格控制时间。第一阶段最容易犯的错是“只看不写”。数据结构模板光看懂了没用必须自己敲一遍尤其是线段树、树状数组、并查集这类代码量比较大的结构考场上没时间让你慢慢回忆。第二阶段建议每天保持3-5道中等题的刷量每道题做完后留出时间写题解把自己当时的思路和最终代码记录下来。第三阶段每周至少安排两次全真模拟模拟时不开IDE自动补全、不查文档完全按照笔试环境来。4.2 必刷题型的优先级排序与理由针对携程技术通用岗的笔试风格我建议按以下优先级排序刷题。第一优先级是动态规划因为携程笔试几乎每一批都会出DP而且难度跨度很广第二优先级是图论的最短路和拓扑排序这些是业务场景题的高频抽象模型第三优先级是并查集和前缀和这类数据结构题代码量不大但细节很多适合作为“保分题”来练。表格形式给大家做个参考优先级题型代表题目方向目标时间高动态规划背包、区间、状压、线性DP5-7天高图论最短路、拓扑排序、并查集4-5天中数据结构线段树、树状数组、单调栈3-4天中字符串KMP、滑窗、Trie基础2-3天低数学GCD、质数筛、组合数1-2天这个表不是绝对的但它反映了我在实际笔试中观察到的题目分布。把时间花在DP和图论上你的下限就有了保障。4.3 笔试现场的时间分配策略笔试现场的时间分配非常关键。以第四批的题量为例总共120分钟我个人的建议是前10分钟快速浏览所有题目给每道题标注难度和预估耗时选做题以外的大题每道控制在35分钟左右留最后15分钟做检查。检查时优先看几个地方数组越界、整型溢出、输入输出格式、边界条件。说实话很多WA不是算法写错了而是这些低级问题。我在一次模拟笔试里就吃过亏题目给了n的范围是10的9次方我用了int存下标和结果求和直接溢出最后调试了20分钟才发现是类型问题。如果你在一道题上卡了超过15分钟立刻止损。先写一个暴力解法拿部分分再跳下一道题。笔试的分数是累计制暴力解的分数和满分解的分数差距没有想象中那么大而如果一道题空着分数就是零。这个策略在时间紧张时尤其重要。5. 高频失分点与排错经验复盘5.1 从WA到AC的典型调试路径我在第四批笔试里最惨痛的一次教训是一道看似简单的贪心题样例过了一提交就WA。我当时整个人都懵了后来冷静下来把调试分成三步才找到问题。第一步自己构造几个随机的测试用例不要用题目给出的样例因为样例太干净了往往会引导你忽略边界条件第二步用小规模的暴力解法做交叉验证如果暴力结果和优化解结果不一致说明逻辑里有个隐藏假设不成立第三步逐行打印中间变量重点看排序后的比较条件是否满足题目的语义。最终定位到的问题非常低级我用了结构体存区间但重载小于运算符时只比较了左端点没有比较右端点。当两个区间左端点相同时排序结果不稳定后续的贪心选择就错了。这类错误在本地调试时很难发现因为编译器不会报错只有输出结果不符合预期时才能反推出来。5.2 常见问题速查与避坑建议问题现象可能原因排查建议显示TLE复杂度估计错误检查是否用了O(n^2)嵌套循环考虑二分优化或换解法显示MLE数据结构过于臃肿检查二维数组大小考虑滚动数组或状态压缩显示WA边界条件漏处理构造空数组、单元素、最小值/最大值、重复值等用例过程中报段错误数组越界或栈溢出查看下标访问是否超过数组长度递归是否过深代码编译失败语法或头文件缺失优先检查是否漏写了#include注意long long和std::命名空间这些问题的排查逻辑放到任何一场笔试中都适用。总的来说笔试现场和平时刷题的最大区别在于平时你可以反复尝试但现场时间有限必须一次写对。所以平时刷题的时候要有意识地培养“一遍过”的习惯不要总觉得反正是练习错了再改就行。真实笔试里改一次代码的时间足够再做一道简单题了。5.3 心态管理与临场发挥的个人体会最后想聊几句心态。经历过秋招的同学应该有共鸣笔试前最焦虑的不是自己不会而是看到讨论区有人说“这次题简单”结果自己打开题目发现第一道就卡住了。实际上讨论区的话不能全信每个人的背景不一样对难度的感知差异很大。我做第四批的时候前面两批的通过率信息已经出来了有人在群里说“这批八成没戏”但最后我认识的好几个同学都顺利进了面试。所以不要被外界信息干扰专注在当下这套题上。还有一个实用技巧笔试前可以花10分钟把常用模板在草稿纸上默写一遍包括并查集、Dijkstra、快速幂、线段树懒标记的框架。不是为了背而是为了唤醒肌肉记忆。真到了考场你会发现写模板的流畅度直接决定你后面的整体节奏前期顺了后面就有自信心去啃难题。这是我复习多场笔试下来最能稳定提分的小习惯。