2023年秋招那阵子我投了途虎养车的后端开发岗。说实话投递的时候主要看中两个点一是途虎在汽车后市场这个赛道里属于头部玩家线下工场店加线上平台的模式跑得比较成熟技术沉淀有一定厚度二是它的后端技术栈以Java为主和我平时练的方向正好匹配。笔试是在牛客网上做的全程两个半小时题量不算小题型也很典型但有几道题带着明显的业务色彩这是让我印象最深的地方。这篇就把整个笔试过程、考点分布、解题思路和复盘经验完整拆一遍给后面准备途虎或者同类互联网公司后端开发笔试的同学做个参考。提示下面内容基于我个人参加笔试后的复盘和同行交流整理题目不是原题复现但考点覆盖方向和解题思路是真实可信的照这个方向准备不会跑偏。1. 途虎秋招后端笔试形式、题量与分值全景1.1 牛客网监考流程与两个半小时的时间账途虎2023届秋招后端开发岗的笔试在牛客网进行全程摄像头监考手机也要扫码进入监控状态这个流程在现在校招里已经是标配了。整场笔试时长150分钟也就是两个半小时放在互联网公司校招笔试里属于中等偏上的配置。题量不小后面做题的时候你能明显感觉到时间是要精打细算的。进入笔试系统之后页面左侧是题目列表右侧是答题区域。编程题支持Java、C、Python提交我自然是选了Java。这里有个很实际的提醒牛客网在线编译器默认的JDK版本是1.8如果你平时用Java 11甚至Java 17的语法写习惯了笔试环境里很可能编译不过。比如var关键字、List.of()这类写法在JDK 1.8下直接报错。另一个容易被忽略的点是输入输出模式。校招笔试基本都是ACM模式需要自己写import、自己写main函数、自己解析输入。如果你平时只在LeetCode上刷核心代码模式的题第一次接触这种模式会很别扭明明思路对的题卡在Scanner和hasNextLine的写法上非常影响心态。我认识不止一个同学笔试的时候因为不熟悉nextInt和nextLine混用导致的换行符问题白白丢了一道题的AC。注意提前至少三天去牛客网熟悉在线编程环境把Java的输入输出模板背下来笔试时没有IDE提示、没有自动补全所有基础代码都得靠手写。1.2 题型分值构成为什么编程题决定生死从分值占比来看编程题是大头三道题加起来占了60%以上的分数剩下的选择题占40%左右。这意味着就算选择题你拿不准只要编程题能AC两道进面试的概率就非常大。我当时的策略是选择题快速过拿不准的题标记一下不纠结把主要时间留给编程题。选择题的考点分布我复盘后大致是下面这个结构知识模块出题数量高频考点Java基础6-8题集合类、HashMap原理、线程池参数、JVM内存模型数据库4-5题SQL语句、索引优化、事务隔离级别计算机网络3-4题TCP三次握手、HTTP状态码、DNS解析流程操作系统3-4题进程线程区别、死锁条件、内存分页设计模式1-2题单例模式、工厂模式业务场景1-2题与汽车养护业务相关的简短场景这个分布和大部分后端开发岗位的笔试考点高度重合核心逻辑就是后端工程师的基础功必须扎实。所以如果你正在准备这类笔试别急着刷偏题怪题把Java集合、并发编程、MySQL索引、TCP/IP这些高频考点吃透性价比是最高的。2. 三道算法题实战拆解从签到题到业务模拟题2.1 签到题里的字符串边界陷阱笔试第一道编程题通常都是“送分题”作用是让你热身找节奏。途虎的第一题是给出一组车辆保养记录的日期字符串要求统计出每个月有多少条记录。听起来很简单就是字符串拆分加哈希表计数但这道题有一个小陷阱日期可能重复而且格式可能不规范比如“2023-09-01”和“2023-9-1”都算合法输入必须按同一个月处理。我提交了一次通过率只有80%就是因为没处理月份和日期可能不带前导零的情况。后来加了一个辅助函数先把字符串拆成年、月、日三个部分转成整数后再格式化成统一的“年-月”字符串再丢进Map计数这才全部通过。public static String normalizeMonth(String date) { String[] parts date.split(-); int year Integer.parseInt(parts[0]); int month Integer.parseInt(parts[1]); return year - String.format(%02d, month); }这道题的核心考点其实是编码习惯和对边界情况的敏感度。提醒大家一点笔试时不要觉得代码能跑通示例用例就没问题了一定要自己构造几个边界用例测一下比如日期只有一天、月份出现“13”、输入的字符串是空的这些情况最容易扣分。2.2 带约束的DP题状态设计比模板更重要第二道题是典型的动态规划题干背景像是“仓库配送最短时间规划”有若干个配送点点与点之间有不同的运输时间要求从起点到终点找一条总时间最小的路径但有限制条件——某些时间点某些路段不能走。这个实际上就是带约束的最短路径问题本质上还是DP但需要把“时间段限制”这个额外维度考虑进去。我当时的思路是把图转成邻接矩阵然后用二维dp数组表示“到达第i个节点且处于时间窗j时的最小累计耗时”。这种状态设计就是常说的“分层图最短路”属于比较进阶的动态规划写法。如果你对这种题型不熟悉建议先从标准最短路径题开始练比如LeetCode 743网络延迟时间、787K站中转最便宜航班这两道题对理解“状态维度扩展”非常有帮助。状态设计 dp[i][j] 到达节点i时间维度为j时的最小耗时 转移方程 dp[next][nextTime] min(dp[next][nextTime], dp[curr][currTime] travelTime)笔试时我没能完全AC过了大概70%的测试用例主要问题出在限制时间段的边界条件处理上。复盘后我意识到这类带额外约束的DP题关键策略是把约束转换成状态的一维不要硬往普通BFS或Dijkstra上套。因为你一旦用Dijkstra会发现状态携带的信息不够用还得额外维护一个数组存每一个时间点的可达性复杂度一下子就上去了。2.3 业务场景模拟题贪心加堆的调度问题第三道题是我觉得最出彩的它结合了途虎的汽车保养业务有N辆汽车排队做保养每辆车有预估的保养工时和预约时间需要设计一个调度方案使所有车辆的平均等待时间最短。这道题让我意识到途虎的笔试题确实在产品层面花了心思不只是考算法还在考你面对真实业务场景时能不能抽象成算法模型。这道题的算法内核是“最短作业优先”调度贪心思路就能解每次都从等待队列中取出预计工时最短的车辆先做。但实际编码时还需要维护一个小根堆同时处理“预约时间未到”的情况。具体做法是初始化时间轴把当前时刻之前已到达的车全部放进小根堆如果堆为空但还有车没到直接把时间跳到下一辆车的到达时间避免空闲等待。PriorityQueueint[] heap new PriorityQueue((a, b) - a[1] - b[1]); Arrays.sort(cars, (a, b) - a[0] - b[0]); int idx 0, curTime 0; long totalWait 0; while (idx cars.length || !heap.isEmpty()) { while (idx cars.length cars[idx][0] curTime) { heap.offer(cars[idx]); } if (heap.isEmpty()) { curTime cars[idx][0]; continue; } int[] task heap.poll(); curTime task[1]; totalWait curTime - task[0]; }这道题我完整AC了因为备考时刷过LeetCode 1834单线程CPU和621任务调度器思路是相通的。这里给大家一个非常实用的建议刷题别只盯着题号和熟练度多想一想这道题在真实业务场景里对应什么情况。这样到了笔试现场看到带业务包装的题目你才能一眼看穿它的算法内核。3. 计算机基础考点梳理Java、数据库、网络全覆盖3.1 Java高频考点HashMap、线程池、JVM途虎后端以Java技术栈为主所以选择题里Java基础占了最大比重。我复盘下来考察最密集的是三个方向HashMap、线程池、JVM内存模型。HashMap的考察方式是“源码细节题”。典型的出题方式包括HashMap的底层数据结构是什么、什么时候从链表转红黑树、加载因子为什么是0.75、并发环境下会出什么问题。这里我想展开说一下加载因子0.75这个点。0.75是时间和空间上的一个折中太小了会频繁触发扩容浪费空间太大了虽然空间利用率高但哈希冲突概率增加链表变长查找效率下降。笔试里如果问到这个值为什么是0.75你要能说出这层权衡逻辑而不只是背一个数字。线程池的考察重点是ThreadPoolExecutor执行流程。有一道经典题核心线程数2、最大线程数4、阻塞队列容量10同时来了15个任务任务怎么分配很多人会记混执行流程这里我建议你按这个顺序去理解先看核心线程是否已满没满就创建核心线程执行满了就丢进队列排队队列也满了才创建非核心线程线程总数达到最大线程数之后还有任务进来就会触发拒绝策略。把这条链路理清楚线程池相关的选择题基本都能做对。JVM部分不会太深重点在堆、栈、方法区的划分以及Minor GC和Full GC的触发时机。常见的考法是给一段代码问哪些对象分配在堆上、哪些在栈上或者问一个线程私有和线程共享的区域分别有哪些。记住一个原则对象实例和数组都是在堆上分配的栈上存的是基本类型变量和对象引用方法区的常量池和静态变量是线程共享的。3.2 数据库SQL与索引优化从GROUP BY到最左前缀数据库考察主要集中在三块SQL编写、索引原理、事务隔离级别。SQL题一般不会太难给两张业务表让你写一个多表联查但会涉及GROUP BY和HAVING的组合这是很经典的考点。我笔试时遇到一道题要求查询出“每个保养项目下订单数超过10条的车型”。这需要先用GROUP BY对车型和保养项目分组统计再用HAVING过滤掉订单数小于等于10的组。很多人会把WHERE和HAVING的用法搞混记住一条核心原则WHERE是在分组之前对原始记录进行过滤HAVING是在分组之后对聚合结果进行过滤。凡是条件里带了聚合函数比如COUNT、SUM、AVG你就必须写在HAVING里。索引优化的高频考点是“最左前缀原则”。给你一个联合索引(a, b, c)问下面哪些查询能用到索引。这里要理解联合索引在B树里不是为三个字段分别建索引而是把(a, b, c)整体拼接成一个键来排序所以查询条件必须从a开始连续匹配只用a能走索引用a和b能走索引用a、b、c也能走。但如果查询条件里只写了b和c就无法走这个联合索引因为它的最左前缀断了。事务隔离级别的考题一般是判断某种并发问题在哪个级别下还会出现。比如读已提交Read Committed能解决脏读但会出现不可重复读可重复读Repeatable Read能解决不可重复读但会出现幻读。MySQL的InnoDB存储引擎默认是可重复读并且通过MVCC加间隙锁在一定程度解决了幻读问题这个细节很多八股文里会提到笔试中如果考到了答出来就是加分项。3.3 计算机网络与操作系统背熟这些就能拿分网络部分在前面的表格里占比不大但出现频率稳定。TCP三次握手的过程和为什么不是两次或四次几乎每年都考。三次握手的本质是双方都要确认自己和对方的收发能力正常两次握手无法让发送方确认接收方的接收能力四次握手又浪费了一次多余的往返。这个解释思路比单纯背过程更能在笔试里帮助你判断变种题。HTTP状态码也是高频考点尤其是302、403、404、500、502这几个。我建议把状态码按类别整理成一张表1xx是信息提示2xx是成功3xx是重定向4xx是客户端错误5xx是服务端错误。这样考试时看到一个陌生的状态码至少能根据首位数字猜出大概含义选择题正确率会提高不少。操作系统部分偏概念判断进程和线程的区别、死锁产生的四个必要条件、虚拟内存和分页机制是常客。死锁的四个条件是互斥、持有并等待、不可剥夺、循环等待。判断题里常常会把其中一个条件换掉来迷惑你比如把“循环等待”改成“有序等待”你要能识别出来这是不构成死锁必要条件的。4. 途虎特色业务场景题与系统设计简答4.1 保养提醒系统如何把业务抽象成技术方案途虎的笔试里出现了几道与汽车养护业务结合比较紧密的选择题和简答题这是它区别于其他互联网公司笔试的地方。比如有一道题用户给车辆绑定了一个保养计划系统需要根据行驶里程和上次保养时间在合适的时间点推送保养提醒问应该采用什么样的系统设计思路。这种题表面上像系统设计实际上考的是你作为后端开发能不能把业务需求拆解成可以落地的技术模块。我当时在草稿纸上大概列了这几个点存储设计用户车辆表、保养记录表、提醒任务表。用户车辆表存车辆基本信息、当前里程、保养周期保养记录表存每次保养的时间、项目和门店提醒任务表用于记录哪些提醒已经发过、哪些还没发。触发方式使用定时任务每小时扫描一次库找出满足条件的车辆生成提醒任务丢进MQ由推送服务异步消费。这样做的原因是放在用户请求链路里实时计算极高峰流量下会把数据库打垮异步化可以把流量削峰填谷。幂等控制每一条提醒任务生成时都写入提醒记录表用vehicle_id加提醒类型做唯一键防止同一个保养计划被重复推送。这个方案不算复杂但逻辑链条完整能看出你有没有系统的后端项目思维。这里也建议大家在校招项目经验里多准备一个带有“定时任务 消息队列 幂等设计”标签的项目因为这类问题在系统设计题里是最常被问到的。4.2 订单评价系统设计简答题的框架化应对除了选择题里的业务场景题途虎笔试最后还有一道选做的简答题主题一般是“设计一个XX系统”或“XX功能如何实现”。我记得那道题是如果让你设计途虎养车的订单评价系统要求从数据库表结构、接口设计、性能优化三个方面展开。这种题是典型的“框架化答题”很多人在笔试现场不知道怎么下笔核心问题在于没有提前整理答题模板。我的经验是这类题不要一上来就写代码先用小标题分模块阐述。数据库表结构可以先列核心字段评价表评价ID、订单ID、用户ID、门店ID、评分、服务标签、评价内容、图片列表、创建时间。在索引层面订单ID要建唯一索引因为一单通常只能评价一次创建时间要建普通索引因为列表页需要按时间倒序分页查询。接口设计要把几个核心接口说清楚提交评价、查询评价列表、回复评价、评价审核。每个接口最好像写接口文档一样把入参、出参、核心逻辑写出来。提交评价要考虑幂等防止前端重复提交导致重复评价查询评价列表要用分页并且控制单次返回数量。性能优化层面可以提三个方向门店维度的评分汇总用Redis缓存不需要实时查库聚合评价图片走对象存储数据库只存访问路径不存二进制内容高频查看的评价列表用Redis做二级缓存缓存穿透时再用布隆过滤器拦一下。我当时时间不够没能在简答题里写得很完整但还是把大框架和关键词先摆上去了。这个策略在时间紧张时很有效你先把能得分的结构化内容写出来再回头补细节描述。5. 备考冲刺与避坑指南5.1 笔试前一周的冲刺清单很多同学问“后端开发学习路线”到底该怎么规划但到了笔试冲刺阶段就不存在完美的学习路线了只有一个原则查漏补缺加模拟实战。笔试前一周我建议你至少做三件事把Java集合、并发、JVM、MySQL索引与事务、TCP/IP这几大块的高频选择题各刷30道重点看错题解析不贪多但每道题都要吃透在牛客网上找几套其他公司Java后端的笔试题完整卡时间模拟一遍严格按150分钟来训练做题节奏和取舍能力把常用的Java输入输出模板、快速排序模板、并查集模板、前缀和模板背熟笔试时直接套用模板能省下大量时间。我见过不少同学LeetCode刷了300多题但笔试成绩很一般原因就是在牛客网这种在线编辑器里写不习惯。所以第2条特别重要一定要在真实的笔试平台环境里模拟而不是在本地IDE里自我感觉良好。5.2 实战时间分配我用了这个节奏我这次笔试实际的时间分配是这样的选择题用了50分钟编程题三道分别用了15分钟、35分钟、30分钟最后剩20分钟检查选择题和补编程题的测试用例。整体节奏还算合理但第二道DP题确实消耗超预期了。这里给大家一个更通用的小时分配策略题型建议用时核心策略单选题30-40分钟会就秒选不会先标记跳过不纠结多选题20-30分钟拿不准的选项宁缺毋滥选错倒扣风险大编程题第一题15分钟必须AC注意边界用例编程题第二题30分钟有思路就试超过25分钟没AC先放编程题第三题30-35分钟先写框架拿部分分再补全细节检查与补测15-20分钟回看标记的选择题补齐边界测试用例这套分配的核心思想是编程题的分值远大于选择题所以时间要向编程题倾斜但也不能完全放弃选择题的检查因为多选倒扣分的情况在校招笔试里很常见。注意在线笔试系统通常不会在提交后立刻告诉你通过率多数是考试结束后统一判分。所以编程题请务必做到“本地测试能跑通 把能想到的边界情况都测一遍”再提交因为每次提交都会消耗时间试错成本比平时刷题高得多。5.3 复盘三个坑时间、选择和边界用例最后说几个实际踩过的坑希望你们能绕开。第一个坑是“太早陷入某一道题”。我第二道DP题花了将近40分钟导致第三道场景模拟题差点没时间做。复盘后发现第二道题如果用“分层状态”的思路20分钟内是可以写出通过代码的但我在Dijkstra的思路上绕了太久。教训是一道题超过20分钟没有清晰思路先放一放等做完其他题再回头看心态一放松思路反而会打开。第二个坑是“选择题过度纠结”。有几道多选题我明知道第一感觉是正确答案但总觉得题里有陷阱反复改来改去最后反而改错了。笔试选择题的“第一感觉”准确率通常很高除非你非常确定某个选项涉及的知识点自己掌握错了否则不要轻易改动答案。这一条在时间压力下尤其重要。第三个坑是“不重视本地测试用例”。我在LeetCode上刷题习惯了核心代码模式到了牛客网的编辑器里输入格式和判题逻辑跟平时不太一样很多边界用例我自己没构造出来就提交了白白浪费了提交次数。从那以后我养成一个习惯不管题目多简单都要在本地跑一下空输入、单元素输入、重复元素输入这几个边界用例再提交。经过这次笔试我个人最大的体会是途虎的笔试并没有特别偏怪的题整体考察的是后端开发岗位最核心的基础能力和算法功底再加上一点点业务思维包装。把Java基础、数据库、计算机网络这些高频考点吃透配合一定量的算法训练和在线笔试模拟通过率其实是很高的。最后再分享一个小技巧笔试开始前十分钟先把输入输出模板在你的编辑器里敲一遍哪怕第一题用不上也能让你快速进入手写代码的状态。希望大家备考路上少走弯路把时间真正花在刀刃上。