1. 项目概述与核心需求拆解最近在帮几个准备华为OD机试的朋友做模拟练习发现“API请求日志去重分析”这个题目出现的频率相当高尤其是在新系统的机试真题里。这题乍一看是个简单的字符串处理但实际做下来你会发现它完美地考察了候选人对数据流处理、边界条件判断以及编程语言基础数据结构如字典、列表的熟练运用。题目本身不涉及复杂的算法但想拿满分细节处理上一点都不能马虎。简单来说它模拟了一个后端系统处理访问日志的场景你需要写一个程序读入一串按时间排序的日志把其中连续重复的API请求路径合并成一条并计算合并后这条请求的总响应时间和平均响应时间。这听起来是不是很像线上监控系统里为了节省存储空间和便于分析对海量日志做的初步聚合操作没错这道题目的实用性就体现在这里。适合谁来参考这篇内容呢首先是正在备战华为OD机试尤其是使用Python或JavaScriptJS的考生这篇文章会给你一个清晰的实现思路和避坑指南。其次对于任何想巩固基础编程能力学习如何处理时序数据、进行数据清洗和简单聚合的开发者这也是一个很好的练手项目。我们会用最“说人话”的方式把题目拆解透并用Python和JS两种语言分别实现你会看到两种语言在解决同一问题时思路的异同这对于拓宽编程视野也很有帮助。2. 题目深度解析与设计思路拿到这个题目我们首先得把需求“翻译”成程序员能理解的语言。根据常见的题目描述虽然我们手头没有完整的原题但结合网络片段和类似题型我们可以梳理出以下几个核心要点2.1 输入数据格式与规则输入通常是一个多行字符串或者是从标准输入读取的多行数据。每一行代表一条日志记录包含两个关键信息请求路径和响应时间单位通常是毫秒。这两个信息之间一般用空格分隔。日志的顺序就是请求发生的时间顺序这一点非常重要是后续“连续”判定的基础。例如一段输入可能长这样/api/user 120 /api/user 150 /api/order 200 /api/user 100 /api/product 80 /api/product 902.2 核心处理逻辑“连续去重”与“聚合统计”这是题目的灵魂所在。处理规则可以分解为三步顺序读取我们必须按照日志的输入顺序进行处理不能打乱。连续判定检查当前日志的请求路径是否与上一条日志的请求路径相同。注意是“连续相同”才合并如果中间被其他请求隔开了即使路径相同也被视为新的独立请求序列的开始。合并计算当遇到连续相同的请求路径时我们不立即输出而是进行“累积”。累积的信息包括路径不变、总响应时间累加、请求次数计数。当读取到的请求路径发生变化或者所有日志都处理完毕时就将之前累积的那“一组”连续请求输出为一条记录。输出的这条记录需要包含请求路径、总响应时间、平均响应时间。平均响应时间通常要求保留整数可能是向下取整或四舍五入需根据题目要求调整常见是保留整数。2.3 输出格式要求输出是处理后的日志每条记录占一行。格式一般也是“路径 总耗时 平均耗时”。接上面的例子处理后的输出应该是/api/user 270 135 /api/order 200 200 /api/user 100 100 /api/product 170 85解释一下前两行/api/user是连续的所以合并总时间120150270平均270/2135。第三行/api/order是独立的。第四行/api/user虽然路径和第一组相同但因为不连续中间有/api/order所以作为新的一组单独输出。最后两行/api/product连续合并输出。2.4 思路设计与选型考量为什么选择这样的思路这背后是典型的在线处理或流式处理思想。我们不需要把所有的日志都先存到一个大列表里再去做复杂的去重分析而是可以一边读一边处理只需要记住“当前正在处理的是哪个路径”以及它的累积状态即可。这非常节省内存尤其适合处理理论上可以无限长的日志流。具体到数据结构我们需要一个“状态存储器”。通常我们会用几个变量current_path: 存储当前正在累积的请求路径。total_time: 存储当前路径累积的总响应时间。count: 存储当前路径连续出现的次数。当读取新的一行日志时比较其路径与current_path如果相同更新total_time和count。如果不同这意味着上一组连续的请求结束了。此时我们需要输出current_path、total_time和计算出的平均时间total_time / count。输出后重置状态存储器将新读入的这条日志作为新一组请求的开始。这里有一个极其关键的边界条件所有日志处理完后最后一组累积的请求状态还在存储器里并没有因为遇到“不同”而被触发输出。因此在循环读取结束后我们必须额外检查并输出这最后一组数据。这是很多初学者容易遗漏导致丢数据或输出不完整的地方。3. Python实现详解与避坑指南Python以其简洁的语法和强大的内置数据结构非常适合处理这类文本分析和数据聚合任务。下面我们一步步实现并穿插讲解注意事项。3.1 基础版本实现我们先写一个最直接、最易理解的版本通常机试时这样写就能通过大部分用例。import sys def process_logs(): # 初始化状态变量 current_path None total_time 0 count 0 results [] # 用于存储输出结果也可以直接打印 # 从标准输入读取所有行 lines sys.stdin.read().strip().splitlines() for line in lines: if not line.strip(): # 跳过空行 continue path, time_str line.split() time int(time_str) # 如果是第一条日志或者路径发生了变化 if current_path is None or path ! current_path: # 如果不是第一条日志需要先输出上一组的结果 if current_path is not None: avg_time total_time // count # 整数除法向下取整 results.append(f{current_path} {total_time} {avg_time}) # 直接打印print(f{current_path} {total_time} {avg_time}) # 开始处理新的一组请求 current_path path total_time time count 1 else: # 路径相同累积 total_time time count 1 # 循环结束后处理最后一组数据 if current_path is not None: avg_time total_time // count results.append(f{current_path} {total_time} {avg_time}) # 直接打印print(f{current_path} {total_time} {avg_time}) # 输出所有结果 print(\n.join(results)) if __name__ __main__: process_logs()3.2 关键代码段解读与注意事项读取输入sys.stdin.read()一次性读取所有输入适用于已知输入结束的场景如机试平台。在真实流式环境中更推荐用for line in sys.stdin:逐行读取。状态初始化current_path None是一个巧妙的设定。用None作为初始值可以清晰地用if current_path is None来判断是否是第一条日志避免了用空字符串可能带来的歧义。整数除法total_time // count使用了地板除确保平均时间是整数。这里是一个重要的坑点务必看清题目要求有些题目可能要求四舍五入那就需要改成round(total_time / count)或者int(total_time / count 0.5)。如果要求保留小数则需使用浮点数除法并格式化输出。边界处理if not line.strip():用于跳过输入中可能存在的空行增强代码健壮性。输出时机注意输出发生在“路径变化时”和“全部处理完后”。这个逻辑顺序保证了每一组连续请求都能被正确输出。3.3 优化与进阶写法上面的代码清晰但我们可以让它更Pythonic逻辑更紧凑。例如使用itertools.groupby可以非常优雅地处理“连续相同项分组”的问题。import sys from itertools import groupby def process_logs_itertools(): lines [line.strip() for line in sys.stdin if line.strip()] # 将每行数据转换为 (路径, 时间) 的元组 logs [(line.split()[0], int(line.split()[1])) for line in lines] results [] # groupby 根据路径分组但需要先确保数据是按路径连续排序的本题输入已保证 for key, group in groupby(logs, keylambda x: x[0]): group_list list(group) # group是一个迭代器需要转成列表来计算 total_time sum(time for _, time in group_list) count len(group_list) avg_time total_time // count results.append(f{key} {total_time} {avg_time}) print(\n.join(results))groupby的强大之处在于它只对连续的相同项进行分组完美契合本题需求。这种写法极大地简化了状态维护的逻辑。但请注意在机试紧张的环境下如果你对groupby不熟悉使用基础版本更稳妥因为它的每一步逻辑你都完全掌控调试起来也更简单。3.4 常见问题与调试技巧问题一输出缺失最后一条或几条记录。原因忘记在循环结束后处理最后一组累积的数据。解决务必在函数末尾添加输出最后一组状态的代码块。问题二平均时间计算错误出现小数或异常。原因使用了浮点除法/但输出时未格式化或者count可能为0虽然本题逻辑下不会但防御性编程可以考虑。解决明确题目对平均时间的要求整数、小数位数使用对应的除法运算符和格式化方法。问题三遇到非数字的响应时间导致程序崩溃。原因输入数据可能不规范。解决添加异常处理例如try: time int(time_str) except ValueError: continue跳过无效行或者根据题目说明假定输入都是合法的。调试技巧在本地测试时不要总是用sys.stdin。可以定义一个字符串变量input_data来模拟输入这样更方便。def test(): input_data /api/user 120 /api/user 150 /api/order 200 /api/user 100 /api/product 80 /api/product 90 # 临时替换sys.stdin为一个StringIO对象 import io sys.stdin io.StringIO(input_data) process_logs()4. JavaScript实现详解与差异对比对于前端工程师或需要用到JS的场合用JavaScript实现同样重要。JS的实现逻辑与Python完全一致但语法和运行环境有区别。我们分别讨论Node.js环境下的实现。4.1 Node.js基础版本实现在Node.js中我们需要使用readline模块来逐行读取标准输入这是一种更接近“流式处理”的方式。const readline require(readline); const rl readline.createInterface({ input: process.stdin, output: process.stdout }); let currentPath null; let totalTime 0; let count 0; const results []; rl.on(line, (line) { const trimmedLine line.trim(); if (!trimmedLine) return; // 跳过空行 const [path, timeStr] trimmedLine.split( ); const time parseInt(timeStr, 10); // 处理逻辑开始 if (currentPath null || path ! currentPath) { // 输出上一组结果如果不是第一组 if (currentPath ! null) { const avgTime Math.floor(totalTime / count); // 向下取整 results.push(${currentPath} ${totalTime} ${avgTime}); } // 开始新的一组 currentPath path; totalTime time; count 1; } else { // 累积 totalTime time; count; } }); rl.on(close, () { // 处理最后一组数据 if (currentPath ! null) { const avgTime Math.floor(totalTime / count); results.push(${currentPath} ${totalTime} ${avgTime}); } // 输出所有结果 console.log(results.join(\n)); process.exit(0); });4.2 JS实现的关键差异与注意事项异步与事件驱动Node.js的核心是异步IO。readline模块通过line事件来推送每一行数据通过close事件来通知输入结束。我们必须把“处理最后一条数据”的逻辑放在close事件回调里而不能放在line事件的循环中。变量声明使用let和const明确变量作用域。状态变量 (currentPath,totalTime,count) 需要在所有事件回调之外声明以便持久化。整数转换与计算parseInt(timeStr, 10)确保将字符串转换为十进制整数。计算平均值时使用Math.floor进行向下取整。同样这里需要根据题目要求选择Math.round四舍五入或其它方式。比较运算符在判断currentPath是否为初始状态时我们使用currentPath null。在JS中使用严格相等运算符可以避免类型转换带来的意外错误。4.3 使用数组Reduce方法的另一种思路如果我们像Python一样先读取所有行到一个数组也可以使用reduce方法进行聚合逻辑上类似于维护一个状态对象。const fs require(fs); // 假设输入从文件读取或者通过其他方式得到了一个行数组 lines const lines ....split(\n).filter(line line.trim()); const initialState { currentPath: null, totalTime: 0, count: 0, results: [] }; const finalState lines.reduce((state, line) { const [path, timeStr] line.trim().split( ); const time parseInt(timeStr, 10); if (state.currentPath null || path ! state.currentPath) { if (state.currentPath ! null) { const avgTime Math.floor(state.totalTime / state.count); state.results.push(${state.currentPath} ${state.totalTime} ${avgTime}); } return { currentPath: path, totalTime: time, count: 1, results: state.results }; } else { return { ...state, totalTime: state.totalTime time, count: state.count 1 }; } }, initialState); // 处理reduce结束后的最后一组数据 if (finalState.currentPath ! null) { const avgTime Math.floor(finalState.totalTime / finalState.count); finalState.results.push(${finalState.currentPath} ${finalState.totalTime} ${avgTime}); } console.log(finalState.results.join(\n));这种函数式编程的风格很简洁但可读性可能略低于命令式的版本且在机试中写起来可能更费时间。它展示了JS处理这类问题的另一种可能性。4.4 JS常见陷阱与性能考量陷阱一浮点数精度JS中所有数字都是双精度浮点数所以totalTime / count即使能整除结果也可能是一个浮点数如5可能表示为5.000000000000001。使用Math.floor可以解决但如果题目要求四舍五入直接使用Math.round(totalTime / count)是安全的。陷阱二输入结束判断在在线判题平台OJ上Node.js程序必须监听close事件才能确保所有输入都处理完毕。如果只在line事件中处理并立即process.exit()可能会丢失最后一部分数据。性能考量对于海量日志readline逐行读取是内存友好的。reduce版本需要先将所有行读入数组可能消耗更多内存。在机试场景下数据量通常可控两种方式均可。5. 测试用例设计与边界情况排查写完代码不是结束设计全面的测试用例进行验证才是保证通过率的关键。以下是一些必须考虑的测试场景5.1 标准功能测试用例输入1 /api/test 100 /api/test 200 /api/another 50 预期输出 /api/test 300 150 /api/another 50 50 输入2 /home 10 /home 20 /home 30 /about 5 预期输出 /home 60 20 /about 5 55.2 边界与异常测试用例单条日志输入/single 999 输出/single 999 999检查点程序是否能正确处理没有“上一组”可比较的情况以及循环结束后是否能输出唯一的一组。所有日志路径都相同输入 /same 1 /same 2 /same 3 输出/same 6 2检查点程序在循环中是否永远不会触发“路径变化”的输出分支确保最终在close事件或循环结束后能正确输出。空输入输入空 输出无输出程序正常结束不报错检查点程序对空输入是否有鲁棒性状态变量初始化后是否会导致除零错误。包含空行的输入输入 /a 100 /a 200 /b 300 输出 /a 300 150 /b 300 300检查点代码中是否有trim()或空行判断逻辑。大数字与平均值取舍输入 /api 3 /api 4 输出/api 7 3 (向下取整) 或 /api 7 4 (四舍五入)检查点平均值计算是否符合题目要求。这是最常见的失分点之一。5.3 排查技巧与调试心得在机试环境中调试手段有限。我个人的经验是先本地验证在本地用上面的测试用例跑通你的代码。可以写一个简单的测试函数批量运行这些用例并对比输出。打印中间状态如果在线提交出错且平台提供错误用例有时只给错误类型可以在代码关键位置添加console.log(JS) 或print(Python) 来输出中间变量如current_path,total_time,count但提交前务必注释或删除这些调试语句。关注初始化与收尾80%的错误发生在循环开始前和结束后。仔细检查状态变量的初始值以及循环结束后是否妥善处理了“未输出”的数据。仔细阅读题目再读一遍题目描述确认输入格式分隔符是空格还是制表符、输出格式平均时间是否需要换行整数还是小数。有时错误就出在这些细节上。6. 从解题到实战日志处理的核心思想延伸这道机试题虽然简单但它提炼了真实日志处理中的一个核心环节按关键字段如路径、用户ID、状态码对连续或窗口内的数据进行聚合。掌握这个基础模式你可以解决很多类似问题。6.1 模式变体与扩展思考非连续去重全局去重如果题目改为“合并所有相同的请求路径无论是否连续”那么解决方案就完全不同了。你需要用一个字典Python或对象JS来按路径聚合所有数据最后再统一输出。这考察的是哈希表的使用。滑动窗口内的聚合更复杂的场景是合并一个时间窗口例如1分钟内的相同请求而不是简单的连续。这就需要引入时间戳字段并按时间排序后使用双指针或队列来维护一个滑动窗口。多字段聚合除了响应时间日志可能还包含状态码、请求体大小等。合并时可能需要同时统计成功请求数、总流量等。6.2 在真实项目中的应用在实际的后端服务中这种日志预处理工作通常不会在业务代码里做而是由日志收集管道如Fluentd, Logstash或流处理框架如Apache Spark Streaming, Apache Flink来完成。它们提供了更强大、更分布式的聚合能力。但原理是相通的定义Key如请求路径定义需要聚合的Value如响应时间、次数然后进行合并计算。例如你可以很容易地将本题的代码改造成一个简单的命令行工具用于快速分析本地的Nginx或应用日志文件找出连续调用频繁的接口这可能是性能瓶颈或循环调用bug的线索。6.3 给备考者的最后建议面对华为OD或其他公司的机试题保持清晰的思路比追求奇技淫巧更重要。对于“API请求日志去重分析”这类题目先理清输入输出用笔画一下样例数据手动模拟合并过程彻底理解规则。设计状态变量想清楚需要几个变量来记录“进行到哪一步了”。注意边界重点考虑“第一条数据”、“最后一条数据”、“没有数据”的情况。写完先自测用我们上面列出的几种边界用例快速验证一遍。代码整洁即使时间紧也尽量让变量名有意义保持适当的缩进。这能帮你减少低级错误。这道题本身不复杂但它像一面镜子能照出你编程习惯的扎实程度。把基础打牢把细节处理好不仅是应对机试更是成为一名优秀开发者的必经之路。
