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(n²)时间复杂度的典型教材案例。

进阶追问：如何用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()。当你发现连空白字符的定义都需要查规范时，或许就理解了为什么大厂把这当作「基础门槛」——不是刁难，是区分「使用者」与「建造者」的最小可行测试。

你最近一次被问到手写实现是什么时候？当时漏掉了哪个现在想起来拍大腿的细节？