LeetCode把54題藏了8年，面試官還在考這個螺旋陷阱

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%。它的價值不在于難度，而在于用最短的代碼量，暴露候選人的工程習慣。