6362人上周在这道题上栽了跟头。不是题目变难了，是很多人还没意识到：矩阵遍历的考法，已经从"会不会写"进化到了"能不能一次写对"。
LeetCode 54题「螺旋矩阵」自2016年上线，至今仍是Google、Meta、字节跳动的面试常客。一道看似简单的数组题，平均通过率却只有47.3%——比多数中等难度题目还低。
为什么面试官偏爱这道题
「螺旋矩阵」的陷阱不在算法复杂度，而在边界条件的处理。候选人往往在白板上写得飞快，却在单行列矩阵、奇偶维度切换时翻车。
Google前工程师Vansh在解题笔记里打了个比方：这就像剥洋葱，每一层剥完都要确认里面还有没有芯。很多人剥到最后一层，要么多剥一次空气，要么把芯落在里面。
题目要求很明确：给定m x n的矩阵，按顺时针螺旋顺序返回所有元素。输入[[1,2,3],[4,5,6],[7,8,9]]，输出必须是[1,2,3,6,9,8,7,4,5]——顺序错一个，测试用例全挂。
2019年字节跳动秋招，这道题出现在3轮技术面中的2轮。一位拿到SSP的候选人事后复盘：「面试官看的不是你知不知道四个方向，而是你在写完循环后，有没有立刻收缩边界。」
四个指针的生死线
标准解法的核心是用四个变量框住当前未遍历的区域：startingRow（起始行）、endingRow（结束行）、startingCol（起始列）、endingCol（结束列）。
遍历顺序固定为四步：从左到右扫顶行，从上到下扫右列，从右到左扫底行，从下到上扫左列。每扫完一边，对应的边界向内收缩1。
真正的坑出现在第三步之后。当你扫完底行、准备向上扫左列时，必须检查count是否已等于总元素数。对于3x3矩阵，扫完底行刚好结束；但对于3x4矩阵，此时还剩一列要处理。
Vansh在代码注释里标红了这一点：「Crucial check: Always check if (count < total_elements) before starting the next phase」。这个if判断漏掉，单行列测试用例必挂。
2023年LeetCode官方统计，54题的错误提交中，31%死于边界收缩顺序错误，24%死于漏掉count检查，19%死于方向顺序搞混。算法本身没错，错在工程细节的完备性。
从面试题到生产代码
这道题的现实映射很直接：图像处理中的像素遍历、游戏地图的层叠渲染、Excel表格的选中区域计算，底层都是类似的边界收缩逻辑。
Meta一位工程师透露，他们内部有个代码规范叫"spiral discipline"——任何涉及多维数组遍历的函数，必须显式声明边界变量，禁止用i++硬编码。这个规范的源头，就是早年太多人在类似逻辑上踩坑。
国内某头部云厂商2024年的校招面经显示，这道题开始出现变种：要求原地修改矩阵而非返回新数组，或者要求逆时针螺旋。核心解法不变，但候选人需要5秒内反应过来如何调整方向顺序。
一位面过6家大厂的算法竞赛选手总结：「螺旋矩阵是面试官的试金石。他们能通过你写代码时的停顿位置，判断你是背过答案还是真正理解。」
8年未变的考点，变了什么
2016年到2024年，这道题的难度标签始终维持"中等"。但通过率从61%掉到47%，不是因为题目变了，是面试官的评判标准变了。
早期能写出四层循环就算通过。现在，面试官会追问：空间复杂度能不能优化？能不能用递归改写？如果矩阵是稀疏存储怎么办？
2024年3月，LeetCode社区有人发帖统计：用Python写出最优解（时间O(mn)、空间O(1)）的平均用时是12分钟，但加上边界检查、异常处理、代码注释，能拖到25分钟。而面试通常只给20分钟。
Vansh的解题模板在GitHub收获了2.3k星。他的代码结构很直白：先算总数，再设四边界，然后while循环套四个for循环，每个for循环后紧跟边界收缩。没有技巧，全是纪律。
一位拿到Google L4的读者在评论区反馈：「面这道题时，我主动讲了单行列的特殊处理，面试官直接跳过后续追问，开始聊项目。」
这道题还能考多久？LeetCode 2024年Q1的面试题库报告显示，54题的出现频率仍排在前15%。它的价值不在于难度，而在于用最短的代码量，暴露候选人的工程习惯。
热门跟贴