JS面試15道手撕題：大廠面試官把trim()源碼當入場券

去年秋招，一位前端候選人在某大廠三面現場遭遇連環追問：「如果String.prototype.trim()明天被瀏覽器廢棄，你能用15分鐘重寫一個嗎？」他后來回憶，那15分鐘決定了年薪檔位。

這不是極端案例。2024年前端崗位JD中，「手寫源碼級實現」出現頻率同比提升217%（某招聘平臺內部數據）。字符串方法polyfill（墊片/兼容性代碼）正從「加分項」變成「基礎門檻」——因為面試官發現，會用API和能造API的人，debug效率差出一個數量級。

為什么字符串方法是面試重災區

JavaScript字符串操作貫穿表單驗證、URL解析、數據清洗、動態UI渲染。但多數開發者停留在「調包俠」階段：知道slice()能截取，卻不清楚它如何處理Unicode代理對；天天用replaceAll()，卻說不出正則回溯的復雜度陷阱。

某字節跳動技術委員會成員在內部分享中直言：「我們招P6+時，手寫polyfill是必選項。不是考記憶力，是觀察候選人能否把語言規范翻譯成可執行邏輯。」

這種考察背后有個殘酷現實：現代框架封裝太厚。React/Vue開發者可能三年沒碰過原生DOM操作，但字符串處理逃不掉——哪怕你用TS寫類型體操，最終還是要操作原始字符串。

15個手撕實現：從ASCII游戲到狀態機

以下實現全部基于ECMAScript規范邏輯，剔除瀏覽器引擎的C++優化層，保留核心算法骨架。建議配合Chrome DevTools的「Show native code」功能對比閱讀。

首字母大寫：firstCap

核心技巧是ASCII碼位運算。小寫字母a-z對應97-122，減32即得大寫。這里有個細節：String.fromCharCode()接收UTF-16編碼單元，但ASCII范圍內與Unicode碼點重合，所以直接減法安全。

面試常挖坑：「如果首字符是emoji怎么辦？」emoji由代理對（兩個16位碼元）組成，charCodeAt(0)只取到高位，減32會產出亂碼。規范級實現需要檢測codePointAt()，但多數面試官接受ASCII限定版——關鍵是展示你對編碼層級的認知。

末字母大寫：lastCap

索引計算是陷阱區。this.length - 1在空字符串時會得到-1，slice(0, -1)行為與預期不符。健壯實現需要前置校驗，但面試場景下，先寫出主干再補邊界，比一開始就追求完美更能展示思維過程。

字符間填充：padBetween

這個實現暴露字符串的「數組幻覺」。this[i]語法讓字符串看起來像字符數組，實則每次訪問都觸發字符串索引轉換。for循環拼接時，頻繁創建中間字符串——V8引擎會優化為rope結構，但手工實現里這是O(n2)時間復雜度的典型教材案例。

進階追問：如何用Array.prototype.join()改寫？答案是一行：this.split('').join(pad)。但split('')對Unicode代理對會拆散emoji，而原實現保留碼元完整性。這就是polyfill的深層價值：迫使你直面規范與實現的縫隙。

trim()的Whitespace定義陷阱

手寫trim()是高頻題，但90%候選人漏掉Unicode空白字符。ECMAScript定義的Whitespace包含：U+0009到U+000D（制表符到回車）、U+0020（普通空格）、U+00A0（不間斷空格）、U+1680、U+2000到U+200A、U+202F、U+205F、U+3000、U+FEFF（BOM）。

正則實現：/^[\s\uFEFF\xA0]+|[\s\uFEFF\xA0]+$/g。但\s在ES5前不包含U+00A0，所以現代polyfill需要顯式枚舉。某美團一面題要求「不用正則實現trim」，標準解法是雙指針從兩端向中心掃描，直到遇到非空白字符。

replaceAll()：從正則到字符串

ES2021引入的replaceAll()，polyfill需要處理兩個分支：首個參數是字符串時，全局替換且不做正則轉義；是正則時，必須帶g標志否則拋TypeError。實現難點在于字符串模式的轉義——$字符在replacement字符串中有特殊含義（$&表示匹配項，$`表示前置等）。

某阿里P7面試題變體：「實現一個replaceAll，要求$字符按字面量處理」。這要求手動替換而非委托給String.prototype.replace，因為原生的$插值無法關閉。

面試現場的降維打擊策略

手撕polyfill時，候選人常犯三類錯誤：一是直接調用其他內置方法（用toUpperCase實現firstCap失去考察意義）；二是忽視邊界條件（空字符串、null/undefined、類型轉換）；三是算法復雜度失控（正則回溯爆炸、循環嵌套）。

推薦應答結構：先寫MVP版本通過主流程，再主動提出邊界加固。比如實現split()時，先處理基礎字符串分割，再補充limit參數、正則分隔符、捕獲組保留等規范細節。這種「迭代式完善」比一步到位更能展示工程思維。

某前Google面試官在博客中分享評分標準：「我關注的不是最終代碼是否完美，是候選人能否說出『這里如果輸入是……就會出問題』。自我挑刺的能力，比背答案珍貴十倍。」

從polyfill到引擎原理

深入字符串方法實現，會自然觸及V8的StringShape優化、扁平化與Cons字符串（rope）結構、以及Inline Cache機制。比如為什么字符串拼接用+比Array.join()快？因為V8對小字符串優化為扁平存儲，+操作觸發特定fast path。

這些知識不會直接出現在面試題面，但當你解釋「為什么我的padBetween用循環而不用遞歸」時，能提到調用棧深度限制和尾遞歸優化，評分檔位會悄然上移。

GitHub上某開源polyfill倉庫（作者Ritam）收集了15種字符串方法的手寫實現，star數已破3k。其README中有段話被多次引用：「每個polyfill都是一次微型編譯器設計——你把ECMAScript規范的人話，翻譯成機器能執行的確定性步驟。」

下次面試前，不妨關掉IDE自動補全，用白紙手寫一遍trim()。當你發現連空白字符的定義都需要查規范時，或許就理解了為什么大廠把這當作「基礎門檻」——不是刁難，是區分「使用者」與「建造者」的最小可行測試。

你最近一次被問到手寫實現是什么時候？當時漏掉了哪個現在想起來拍大腿的細節？