入行做前端的第十三年我手机里存得最多的截图不是美女也不是账单而是各种线上 bug 现场。其中最有意思的一类是那种看起来完全不像字符串问题的字符串问题搜索框输入“mac”却把“mackbook”也搜了出来价格栏拼出来少了个小数点省份联动明明有数据却匹配不上。每次一层层查到最后都会发现罪魁祸首不是别的东西就是 JS 里最不起眼的字符串。前端每天打交道最多的数据类型, 除了对象和数组, 就是字符串。但越基础的东西越容易被乱用。我在代码评审里见过太多把字符串当成“万能拼接容器”的写法, 也在面试里见过太多只会背 API 却搞不懂字符串底层规则的候选人。这篇文章不说源码, 不列冷门文档, 就把这些年踩过的、看别人踩过的高频字符串坑一个个掰开揉碎讲清楚背后的原因再给出能直接抄走的解法。1. 字符串的基本盘你以为的“值”其实是个住在内存里的“永久居民”1.1 字符串不可变性为什么每次拼接都像重新造房子先讲一个最底层的原理JS 里的字符串是 immutable 的也就是不可变。一旦创建了一个字符串它里面的内容就不会改变。很多人写过这种代码let str hello; str world;看起来像是往str这个变量后面追了一段字符其实真实过程是引擎先把原字符串hello复制一份再拼上 world生成一个全新的字符串hello world最后让变量str指向这个新字符串。原来的那个hello就变成了等待垃圾回收的临时对象。这个特性的直接后果是字符串所有的“修改类”方法比如replace、trim、slice、toUpperCase都不会改变原字符串而是返回一个新的字符串。如果你习惯用对象思维以为调用完方法原变量就被改了第一波 bug 就来了。我见过有人用str.trim()之后继续用str去判断结果字符串前后空格还在界面校验怎么都不通过。循环拼接字符串也是一个经典话题。如果循环一万次每次执行str x按照字符串不可变的语义会产生大量的临时字符串时间效率上确实不划算。现代 JS 引擎比如 V8 做了一些优化引入了场景下的延迟拼接机制但“不要在大循环里直接拼字符串”依然是值得遵守的习惯。更优雅的做法是用数组收集片段最后一次性joinconst parts []; for (let i 0; i 10000; i) { parts.push(x); } const str parts.join();这背后不是玄学是思路上的转变既然每次拼接都是“再造一个房子”那就别一砖一瓦地来回搬先把砖堆好再一次性砌墙。理解了这个特性很多性能问题和 bug 都能提前消灭。1.2 字符串比较的连环坑、、隐式类型转换另一个造成 bug 的根源是字符串和数字的比较。接口返回的 id 往往是字符串123从路由参数里拿到的参数也默认是字符串然后你在代码里写if (id 123)就会发现永远走不进那个分支。更让人无语的是如果用if (id 123)能走进分支但会触发一堆代码规范的爆红提示而且隐式转换还会掩盖真正的问题。我自己总结了一条非常实用的原则线上数据在比较之前要么全转字符串比较要么全转数字比较不要一半一半。比如const fromAPI 123; const fromRoute 123; if (String(fromAPI) String(fromRoute)) { // 稳定可靠 }如果字段本身可能是null或undefined情况会更微妙。String(null)会得到字符串nullString(undefined)会得到undefined这些看起来没问题但一旦拼到页面上或者传给后端就不是用户想要的内容。我推荐封装一个小工具const safeString (v) (v null ? : String(v));还有一类比较坑来自用户输入的空格和大小写。 123 ! 123这几乎是必然的。所以做登录、校验、筛选之前先trim()一下能挡掉不少弱智 bug。做邮箱匹配的时候很多人会先toLowerCase()再比较这个方向是对的但要注意语言环境问题稍后我会专门讲到。2. 字符串拼接和格式化最容易被“乱造”的高发区2.1 模板字符串不是万能树洞嵌套太深就是烧烤现场ES6 之后的模板字符串让我们告别了“加号地狱”但有些人用着用着又把它变成了“另一个地狱”。我在代码里见过这种写法const text 本次${ order.type 1 ? (order.subType a ? 普通商品 : 特殊商品) : 其他 }共${ order.items.reduce((s, i) s i.amount, 0) }件;这能运行但你让后面接手的同事怎么读让半夜来排查 bug 的你怎么办模板字符串的本意是把“已经算好的变量”嵌入到固定文案中不是让你把一整段业务逻辑都塞进${}里面。正确的做法是先把复杂逻辑算成变量再去拼模板const typeMap { 1: 普通商品, 2: 特殊商品 }; const typeLabel order.type 1 ? (typeMap[order.subType] || 未知) : 其他; const totalCount order.items.reduce((s, i) s i.amount, 0); const text 本次${typeLabel}共${totalCount}件;这样一眼就能看清楚文案是什么、每段变量从哪来、有没有兜底。代码不是写给自己一个人看的模板字符串里面嵌套超过一层就已经是坏味道了。模板字符串的另一个翻车点是访问可能为空的字段const text 欢迎 ${user.name} 回来; // 如果 user 是 null这里直接就是 TypeError这种问题在正常数据下不会出现一旦后端某天没返回用户信息整个页面直接白屏。所以复杂模板前面最好加空值兜底或者用可选链const text 欢迎 ${user?.name ?? 访客} 回来;?.和??是现代前端处理字符串拼接时必须熟练的防护组合。别嫌麻烦线上白屏和这个比起来麻烦得多。2.2 URL 参数拼接90% 的中文乱码都死在这里只要有搜索、分页、筛选功能就一定会有 URL 拼接。最常见的错误写法是直接把参数拼进去const url /api/list?page page size size kw keyword;如果keyword是“前端 JS”这种内容拼出来的 URL 里既有中文又有空格还有符号。浏览器可能会自动编码一部分但不会全部按你的预期处理服务端解析时就容易乱码或者参数错位。正确方案是用URLSearchParamsconst params new URLSearchParams({ page, size, kw: keyword }); const url /api/list?${params.toString()};它会自动把中文、空格、、这些特殊字符做百分号编码服务端拿到之后也能正确解码。如果项目要兼容较老的浏览器至少也要记得用encodeURIComponent包住每一个参数值const url /api/list?page${page}size${size}kw${encodeURIComponent(keyword)};这里很容易犯一个错有人图省事把整个 URL 传给encodeURIComponent结果连?和这种结构字符都被编码了服务端收到一个看不懂的路径。记住encodeURI处理整个 URLencodeURIComponent只处理参数值命名已经暗示了各自的分工。2.3 大批量拼接join 比加法优雅也比加法稳如果有一个数组需要拼成用逗号分隔的字符串或者拼成一段 HTML新手会很喜欢用循环拼接let listStr ; for (const item of items) { listStr li item.name /li; }短循环没问题但一旦item.name里含有引号、、、这些字符你拼出来的 HTML 不仅可能被浏览器解析错误还可能成为 XSS 的攻击入口。这已经不是字符串本身的问题而是“以为字符串拼接能解决所有渲染问题”造成的。如果只是纯文本拼接我建议const parts items.map((item) item.name).join(, );如果是渲染 HTML尽量用框架的模板能力去渲染并且把用户输入的特殊字符转义。用户输入的内容永远不应该直接拼进 HTML 或脚本代码里。2.4 别忘了JSON.stringify也是字符串生产者最后补一个很多人没意识到的点JSON.stringify的返回值也是字符串。它看起来不起眼但同样有坑。对象里有undefined、函数、Symbol时这些字段会被静默跳过遇到BigInt时它会直接抛错JSON.stringify({ a: undefined, b: 1n }); // Uncaught TypeError: Do not know how to serialize a BigInt如果要把对象拼到日志、请求体或者字符串模板里别光依赖JSON.stringify要先想清楚数据里有没有不允许序列化的类型。人家明明抛错了你还在那排查了半天“为什么接口没数据”这种场景我在工位上遇到太多次了。3. 判断字符串“包含”和“属于”别再到处indexOf -1了3.1includes说的是人话indexOf说的是机器话判断一个字符串是否包含另一个字符串老代码里到处是indexOfif (string.indexOf(目标) -1) { // ... }这本身没有错就是读起来费劲。ES6 之后语义化更好的includes已经非常普及if (string.includes(目标)) { // ... }还需要判断前缀、后缀时用startsWith和endsWithurl.startsWith(/api/); filename.endsWith(.pdf);这些方法默认区分大小写。如果你希望忽略大小写可以统一转小写再比if (input.trim().toLowerCase().includes(keyword.toLowerCase())) { // ... }这里有一个隐藏小坑abc.includes()返回true因为空字符串被认为是任意字符串的子串。如果keyword可能为空一定要先过滤条件否则你会在列表筛选时看到所有数据都返回了产品还以为是接口缓存问题。3.2 包含判断里的正则陷阱用户输入是用来匹配的不是用来执行的当你要根据用户输入做搜索时经常会有人想用正则const reg new RegExp(keyword, i);如果用户输入了.*、[、(这样的正则元字符轻则匹配结果和预期完全不一样重则导致正则在某些极端输入下灾难性回溯页面直接卡死。写一个转义函数并不难const escapeReg (input) input.replace(/[.*?^${}()|[\]\\]/g, \\$); const reg new RegExp(escapeReg(keyword), i);如果你只需要包含判断直接用includes会更省事根本不需要动正则。顺便说一句“用字符串动态调用函数”也是同一个道理。比如你写window[key]()而这个key恰好来自用户输入那就不只是 bug 问题而是安全级别的风险。正确的做法是维护一个白名单映射const handlers { detail: handleDetail, edit: handleEdit }; const fn handlers[action]; if (typeof fn function) { fn(); }永远别让用户输入的字符串直接变成可执行代码的一部分。3.3 “同字不同码”Unicode 归一化是隐藏必考题中文照样有匹配的坑。最典型的是全角和半角和(看起来是两种东西直接includes永远匹配不上。用户搜索“前端(基础)”用的是半角括号内容里存的是全角括号这种情况下必须做转换或归一化。另一个更隐蔽的问题来自 Unicode 的多种编码形式。比如带重音的字符é可以是一个单独码点U00E9也可以是字母e后面加一个组合重音符号U0301。它们渲染出来几乎一样但字符串不相等。解决办法是用normalizeconst a é; const b e\u0301; console.log(a b); // false console.log(a.normalize() b.normalize()); // true这种“长得一样却不相等”的问题在英文和法语内容里尤其常见。如果多语言输入来自不同的系统比较之前做一次normalize(NFC)能省掉不少排查时间。4. 字符串长度与编码JS 的length不是你以为的那个“字符数”4.1length数的是 UTF-16 码元不是肉眼字符很多前端初学者看到abc.length 3就以为length是字符数。直到遇到 emojiconsole.log(.length); // 2 console.log(.length); // 2原因是 JS 内部使用 UTF-16 编码像 emoji 这类超出基本平面的字符需要两个码元来表示也就是所谓的代理对。length返回的是码元数量所以看起来是一个字符返回却是 2。如果产品需求是“最多输入 10 个字符”直接用str.length 10判断用户输入几个 emoji 就会出问题。我之前做过一个评论框用户发一个“笑哭”表情就占了两个长度导致他只能打半句话后台还一直报“长度不足”最后改成按字符数计算才解决。正确计算字符数的方法const countChars (str) Array.from(str).length;Array.from能按码点拆分大多数 emoji 都能正确统计。如果需要处理更复杂的组合字符比如这种用零宽连接符拼起来的家庭表情就要用Intl.Segmenterconst countGraphemes (str) [...new Intl.Segmenter(zh, { granularity: grapheme }).segment(str)].length;现代浏览器对Intl.Segmenter的支持已经很好了遇到这种需求只管用。4.2 截断字符串不能简单slice当你要做列表摘要、面包屑截断、标题隐藏时大家都会想到sliceconst str 这是一段测试文本; str.slice(0, 6);问题是slice是按 UTF-16 码元来切的碰到 emoji 很有可能把一个完整的字符切成两半轻则显示成乱码重则导致后续拼接时出现异常字符。稳妥做法是先把字符串按可见字符拆开再截断function safeTruncate(str, max, suffix …) { const chars Array.from(str); const visible chars.slice(0, max); return chars.length max ? visible.join() suffix : str; } console.log(safeTruncate(这是一段测试文本, 5));这个方案对大多数场景够用了。如果是生产环境面对肤色 emoji、组合表情可以用Intl.Segmenter按“用户感知的字符”来切分。总之别无脑slice字符串截断看起来越简单越容易在边界上炸给你看。4.3 字节长度接口不认字符只认字节服务端存储、数据库字段、日志系统很多时候按字节数限制长度。一个中文字符在 UTF-8 下可能占 3 个字节一个 emoji 占 4 个字节。所以不能用str.length当作字节长度。浏览器自带的 API 可以帮你算new TextEncoder().encode(str).length; // 或者 new Blob([str]).size;TextEncoder是标准 API性能不错也不需要额外依赖。如果你在面试里被问到“怎么计算字符串字节数”能说出这个方案比手写一个 UTF-8 编码循环更符合工程思维。还有一个沟通层面的经验产品说“最多 20 字”你要在需求评审时确认这到底是“20 个字符”还是“20 个字节”。很多后端同学会默认按字节校验前端按字符限制两边标准不一致就会出现“前端明明限制了后端依然报长度错误”的尴尬局面。5. 字符串和数组、数字互转每一个方向都有翻车姿势5.1split与join不是互相逆运算split把字符串拆成数组join把数组拼成字符串看起来是一对但细节里全是坑。abc.split(); // [a, b, c] .split(,); // [] 1,2,,.split(,); // [1, 2, , ] [1, 2, null, undefined].join(,); // 1,2,,注意[null, undefined]在join时会变成空字符串这在生成 CSV、接口参数时经常造成数据错位。如果数组元素可能是空值先过滤再 join或者显式转成空串。另外.split()会返回两个乱码字符原因还是代理对的问题。想要按真实字符拆分用Array.from或展开运算符Array.from(ab); // [a, , b]如果你只是按某个分隔符拆分常规字符串split当然没问题。但涉及 emoji 时记得它有这个限制。5.2 字符串转数字parseInt、Number、三兄弟这是面试高频也是实际 bug 高发区。三个核心差异必须记清楚parseInt(123abc)返回123。它会从左到右解析遇到非数字字符就停。Number(123abc)返回NaN。它要求整个字符串都是合法的数字。123abc也返回NaN和Number的行为基本一致。parseInt(0x10)会按十六进制解析返回16因为parseInt支持十六进制前缀。parseInt(08)建议显式传入进制参数10避免老环境下的奇怪解析行为。如果你要解析用户输入的价格、数量建议先校验再转换function toSafeNumber(input) { const num Number(input); return Number.isFinite(num) ? num : 0; }如果保留小数别用parseFloat(str).toFixed(2)走一圈因为toFixed返回的是字符串后面再做数学运算时会得到意外的拼接结果。想要数字结果可以用Number(num.toFixed(2))或者Math.round。5.3 数组转字符串toString只适合简单场景前端经常要把数组传给后端。直接用arr.toString()会默认用逗号连接得到1,2,3。如果数组元素本身含有逗号后端再按逗号拆分时数据就已经损坏了[a,b, c].toString(); // a,b,c语义丢失这种情况下老老实实用JSON.stringify(arr)或者选一个自定义分隔符const ids arr.map((id) String(id)).join(,);另外不要用String(arr)去替代JSON.stringify(arr)序列化对象。String({})会返回字符串[object Object]。别笑我真的见过有人把对象直接拼进 URL 参数后台日志里全是[object Object]排查了半天还以为是接口问题。5.4 大小写转换的 locale 问题toLowerCase和toUpperCase看起来相当无脑但遇到土耳其语等特殊 locale 时会有奇怪行为。比如土耳其语的I小写是ı不带点而不是常见的i。如果你的产品只服务中英文问题不大但如果做成国际化产品就要注意语言环境。Hello.toLocaleLowerCase(tr);这类问题在代码评审里很少被注意到但一旦遇到真实用户会被当成本地化 bug 提过来。那种“明明代码没变怎么国外用户就报错了”的问题很多时候就是这些细节造成的。6. 一些“看起来很猛”的字符串操作其实一写就错6.1 字符串排序别直接sort()中文会很受伤字符串排序是前端面试题里的常客但实际业务里更容易踩坑。先看最经典的[b, a, c].sort(); // [a, b, c] [10, 9, 1].sort(); // [1, 10, 9]字典序不是数字序所以数字字符串排序之前要先转成数字[10, 9, 1].sort((a, b) Number(a) - Number(b));中文排序的问题更大。直接按 Unicode 码点排序得到的结果通常不是我们认知里的拼音顺序。要按拼音排用localeCompare[张三, 李四, 王五].sort((a, b) a.localeCompare(b, zh-Hans-CN));但有一个需要留意的地方localeCompare的结果依赖浏览器或操作系统的 ICU 数据不同环境可能会有细微差异。如果是后端要拿这个顺序去做分页前端展示和接口返回顺序不一致就会让人很崩溃。顺序要求严格时宁可在后端排好前端不要硬扛。6.2 字符串逆序split().reverse().join()对 emoji 不友好经典面试题“反转字符串”最常见答案是const reverseStr (str) str.split().reverse().join();这个解法对 ASCII 没问题对中文也基本没问题但遇到 emoji 就会拆坏因为split()按码元拆分会把代理对切成两半。稍微改进一下const reverseStr (str) Array.from(str).reverse().join();如果还有更复杂的组合字符可以用Intl.Segmenter按用户感知的字符切分然后反转。面试时如果能主动提到Array.from处理 emoji就已经比大多数候选人想得深了一层。6.3 用字符串动态访问对象属性省市区联动的常见 bug做省市区三级联动时接口经常返回const regionData { 110000: { name: 北京市, children: { 110101: { name: 东城区 } } } };前端拿到用户选中的 code然后通过data[code]去取数据。坑在什么地方code 如果是从option的 value 拿的通常是字符串从某个组件拿的可能是数字也可能是undefined。一旦类型对不上data[code]就会返回undefined页面就“有数据却匹配不上”。稳妥写法是显式转字符串const province regionData[String(code)] ?? {};另外如果通过字符串拼接生成 key比如data[province_ code]要确保中间没有多余空格或换行。我见过因为数据源里有不可见字符导致 key 对不上整个联动一直不显示下一级最后一行一行打印 key 才发现问题。这种 bug 非常消耗时间。6.4 从字符串到“可执行代码”的诱惑要克制热词里有“通过字符串调用函数”这确实是前端面试会问的点。但工程实践上我强烈建议用映射表而不是eval或new Function。eval不仅危险还会让调试变得很困难因为代码在运行时才生成断点、报错、堆栈信息全部乱了。const actionMap { login: () doLogin(), logout: () doLogout() }; const action login; const fn actionMap[action]; if (fn) fn();这种写法安全、可读、好调试。面试里考察“通过字符串调用函数”本质上不是让你炫技而是看你知道不知道反射式调用的风险和替代方案。7. 问题排查与自查清单把这些刻进肌肉记忆7.1 常见问题速查表这里整理一份我平时 code review 会对照的速查表基本覆盖了上文的大部分坑。场景反面教材推荐做法判断包含str.indexOf(x) -1str.includes(x)URL 参数拼中文直接拼接URLSearchParams或encodeURIComponent字符长度str.length限制用户输入Array.from(str).length或Intl.Segmenter截断字符串str.slice(0, 10)直接截先按可见字符拆分再截断字符串转数字parseInt(123px)当合法数字Number(str)并Number.isFinite校验数组转字符串传后端arr.toString()明确分隔符或 JSON 序列化比较 idif (id 123)统一String(id) String(123)用户输入做正则new RegExp(keyword)先转义或直接用includes中文排序[中,文].sort()localeCompare字符串反转str.split().reverse().join()Array.from(str).reverse().join()表格里的每一行都是我在真实项目里见到过的 bug 原型。你不需要把每个 API 都背下来但看到这些关键词时脑子里要能立刻弹出“这里可能会炸”的警报。7.2 提交代码前花三分钟检查字符串我自己的流程是写完涉及字符串的代码后问自己四个问题。第一这个变量的值可能是null或undefined吗如果是有没有兜底第二这个字符串是给用户看的还是给后端传的给用户看有没有转义给后端传有没有编码第三这个长度是字符数还是字节数产品到底要哪个第四这段字符串操作经得起 emoji、中英文混排、全角半角的考验吗这几个问题问完十个 bug 能提前杀掉八个。特别是第一和第二个问题几乎覆盖了线上问题的两大来源空值和编码。7.3 面试官考察字符串时重点从来不是 API最后补充一点个人观察。前端面试题里经常出现“js 判断字符串是否包含”“字符串排序”这类题目本质上是在看“你有没有把字符串当成一个有编码、有不可变性、有隐式转换风险的数据类型来理解”。背一堆 API 名不如现场说出一句“JS 字符串是 UTF-16 码元的序列所以 length 不等于用户感知的字符数”这句话比背五个方法都更能打动面试官。项目开发也是一样真正让你加班改 bug 的往往不是没记住某个方法而是没搞懂字符串在引擎、网络、展示这三层里的真实形态。把这些底层约束吃透很多 bug 从一开始就不会发生。我个人的体会是想写少 bug 的前端不需要记住所有字符串 API但一定要理解“一个字符串从哪里来、要到哪里去、中间经过了什么转换”。把这条线理清楚你的代码评审通过率会比别人高一大截。
前端字符串处理避坑指南：从不可变性到 Unicode 编码的实战解析
入行做前端的第十三年我手机里存得最多的截图不是美女也不是账单而是各种线上 bug 现场。其中最有意思的一类是那种看起来完全不像字符串问题的字符串问题搜索框输入“mac”却把“mackbook”也搜了出来价格栏拼出来少了个小数点省份联动明明有数据却匹配不上。每次一层层查到最后都会发现罪魁祸首不是别的东西就是 JS 里最不起眼的字符串。前端每天打交道最多的数据类型, 除了对象和数组, 就是字符串。但越基础的东西越容易被乱用。我在代码评审里见过太多把字符串当成“万能拼接容器”的写法, 也在面试里见过太多只会背 API 却搞不懂字符串底层规则的候选人。这篇文章不说源码, 不列冷门文档, 就把这些年踩过的、看别人踩过的高频字符串坑一个个掰开揉碎讲清楚背后的原因再给出能直接抄走的解法。1. 字符串的基本盘你以为的“值”其实是个住在内存里的“永久居民”1.1 字符串不可变性为什么每次拼接都像重新造房子先讲一个最底层的原理JS 里的字符串是 immutable 的也就是不可变。一旦创建了一个字符串它里面的内容就不会改变。很多人写过这种代码let str hello; str world;看起来像是往str这个变量后面追了一段字符其实真实过程是引擎先把原字符串hello复制一份再拼上 world生成一个全新的字符串hello world最后让变量str指向这个新字符串。原来的那个hello就变成了等待垃圾回收的临时对象。这个特性的直接后果是字符串所有的“修改类”方法比如replace、trim、slice、toUpperCase都不会改变原字符串而是返回一个新的字符串。如果你习惯用对象思维以为调用完方法原变量就被改了第一波 bug 就来了。我见过有人用str.trim()之后继续用str去判断结果字符串前后空格还在界面校验怎么都不通过。循环拼接字符串也是一个经典话题。如果循环一万次每次执行str x按照字符串不可变的语义会产生大量的临时字符串时间效率上确实不划算。现代 JS 引擎比如 V8 做了一些优化引入了场景下的延迟拼接机制但“不要在大循环里直接拼字符串”依然是值得遵守的习惯。更优雅的做法是用数组收集片段最后一次性joinconst parts []; for (let i 0; i 10000; i) { parts.push(x); } const str parts.join();这背后不是玄学是思路上的转变既然每次拼接都是“再造一个房子”那就别一砖一瓦地来回搬先把砖堆好再一次性砌墙。理解了这个特性很多性能问题和 bug 都能提前消灭。1.2 字符串比较的连环坑、、隐式类型转换另一个造成 bug 的根源是字符串和数字的比较。接口返回的 id 往往是字符串123从路由参数里拿到的参数也默认是字符串然后你在代码里写if (id 123)就会发现永远走不进那个分支。更让人无语的是如果用if (id 123)能走进分支但会触发一堆代码规范的爆红提示而且隐式转换还会掩盖真正的问题。我自己总结了一条非常实用的原则线上数据在比较之前要么全转字符串比较要么全转数字比较不要一半一半。比如const fromAPI 123; const fromRoute 123; if (String(fromAPI) String(fromRoute)) { // 稳定可靠 }如果字段本身可能是null或undefined情况会更微妙。String(null)会得到字符串nullString(undefined)会得到undefined这些看起来没问题但一旦拼到页面上或者传给后端就不是用户想要的内容。我推荐封装一个小工具const safeString (v) (v null ? : String(v));还有一类比较坑来自用户输入的空格和大小写。 123 ! 123这几乎是必然的。所以做登录、校验、筛选之前先trim()一下能挡掉不少弱智 bug。做邮箱匹配的时候很多人会先toLowerCase()再比较这个方向是对的但要注意语言环境问题稍后我会专门讲到。2. 字符串拼接和格式化最容易被“乱造”的高发区2.1 模板字符串不是万能树洞嵌套太深就是烧烤现场ES6 之后的模板字符串让我们告别了“加号地狱”但有些人用着用着又把它变成了“另一个地狱”。我在代码里见过这种写法const text 本次${ order.type 1 ? (order.subType a ? 普通商品 : 特殊商品) : 其他 }共${ order.items.reduce((s, i) s i.amount, 0) }件;这能运行但你让后面接手的同事怎么读让半夜来排查 bug 的你怎么办模板字符串的本意是把“已经算好的变量”嵌入到固定文案中不是让你把一整段业务逻辑都塞进${}里面。正确的做法是先把复杂逻辑算成变量再去拼模板const typeMap { 1: 普通商品, 2: 特殊商品 }; const typeLabel order.type 1 ? (typeMap[order.subType] || 未知) : 其他; const totalCount order.items.reduce((s, i) s i.amount, 0); const text 本次${typeLabel}共${totalCount}件;这样一眼就能看清楚文案是什么、每段变量从哪来、有没有兜底。代码不是写给自己一个人看的模板字符串里面嵌套超过一层就已经是坏味道了。模板字符串的另一个翻车点是访问可能为空的字段const text 欢迎 ${user.name} 回来; // 如果 user 是 null这里直接就是 TypeError这种问题在正常数据下不会出现一旦后端某天没返回用户信息整个页面直接白屏。所以复杂模板前面最好加空值兜底或者用可选链const text 欢迎 ${user?.name ?? 访客} 回来;?.和??是现代前端处理字符串拼接时必须熟练的防护组合。别嫌麻烦线上白屏和这个比起来麻烦得多。2.2 URL 参数拼接90% 的中文乱码都死在这里只要有搜索、分页、筛选功能就一定会有 URL 拼接。最常见的错误写法是直接把参数拼进去const url /api/list?page page size size kw keyword;如果keyword是“前端 JS”这种内容拼出来的 URL 里既有中文又有空格还有符号。浏览器可能会自动编码一部分但不会全部按你的预期处理服务端解析时就容易乱码或者参数错位。正确方案是用URLSearchParamsconst params new URLSearchParams({ page, size, kw: keyword }); const url /api/list?${params.toString()};它会自动把中文、空格、、这些特殊字符做百分号编码服务端拿到之后也能正确解码。如果项目要兼容较老的浏览器至少也要记得用encodeURIComponent包住每一个参数值const url /api/list?page${page}size${size}kw${encodeURIComponent(keyword)};这里很容易犯一个错有人图省事把整个 URL 传给encodeURIComponent结果连?和这种结构字符都被编码了服务端收到一个看不懂的路径。记住encodeURI处理整个 URLencodeURIComponent只处理参数值命名已经暗示了各自的分工。2.3 大批量拼接join 比加法优雅也比加法稳如果有一个数组需要拼成用逗号分隔的字符串或者拼成一段 HTML新手会很喜欢用循环拼接let listStr ; for (const item of items) { listStr li item.name /li; }短循环没问题但一旦item.name里含有引号、、、这些字符你拼出来的 HTML 不仅可能被浏览器解析错误还可能成为 XSS 的攻击入口。这已经不是字符串本身的问题而是“以为字符串拼接能解决所有渲染问题”造成的。如果只是纯文本拼接我建议const parts items.map((item) item.name).join(, );如果是渲染 HTML尽量用框架的模板能力去渲染并且把用户输入的特殊字符转义。用户输入的内容永远不应该直接拼进 HTML 或脚本代码里。2.4 别忘了JSON.stringify也是字符串生产者最后补一个很多人没意识到的点JSON.stringify的返回值也是字符串。它看起来不起眼但同样有坑。对象里有undefined、函数、Symbol时这些字段会被静默跳过遇到BigInt时它会直接抛错JSON.stringify({ a: undefined, b: 1n }); // Uncaught TypeError: Do not know how to serialize a BigInt如果要把对象拼到日志、请求体或者字符串模板里别光依赖JSON.stringify要先想清楚数据里有没有不允许序列化的类型。人家明明抛错了你还在那排查了半天“为什么接口没数据”这种场景我在工位上遇到太多次了。3. 判断字符串“包含”和“属于”别再到处indexOf -1了3.1includes说的是人话indexOf说的是机器话判断一个字符串是否包含另一个字符串老代码里到处是indexOfif (string.indexOf(目标) -1) { // ... }这本身没有错就是读起来费劲。ES6 之后语义化更好的includes已经非常普及if (string.includes(目标)) { // ... }还需要判断前缀、后缀时用startsWith和endsWithurl.startsWith(/api/); filename.endsWith(.pdf);这些方法默认区分大小写。如果你希望忽略大小写可以统一转小写再比if (input.trim().toLowerCase().includes(keyword.toLowerCase())) { // ... }这里有一个隐藏小坑abc.includes()返回true因为空字符串被认为是任意字符串的子串。如果keyword可能为空一定要先过滤条件否则你会在列表筛选时看到所有数据都返回了产品还以为是接口缓存问题。3.2 包含判断里的正则陷阱用户输入是用来匹配的不是用来执行的当你要根据用户输入做搜索时经常会有人想用正则const reg new RegExp(keyword, i);如果用户输入了.*、[、(这样的正则元字符轻则匹配结果和预期完全不一样重则导致正则在某些极端输入下灾难性回溯页面直接卡死。写一个转义函数并不难const escapeReg (input) input.replace(/[.*?^${}()|[\]\\]/g, \\$); const reg new RegExp(escapeReg(keyword), i);如果你只需要包含判断直接用includes会更省事根本不需要动正则。顺便说一句“用字符串动态调用函数”也是同一个道理。比如你写window[key]()而这个key恰好来自用户输入那就不只是 bug 问题而是安全级别的风险。正确的做法是维护一个白名单映射const handlers { detail: handleDetail, edit: handleEdit }; const fn handlers[action]; if (typeof fn function) { fn(); }永远别让用户输入的字符串直接变成可执行代码的一部分。3.3 “同字不同码”Unicode 归一化是隐藏必考题中文照样有匹配的坑。最典型的是全角和半角和(看起来是两种东西直接includes永远匹配不上。用户搜索“前端(基础)”用的是半角括号内容里存的是全角括号这种情况下必须做转换或归一化。另一个更隐蔽的问题来自 Unicode 的多种编码形式。比如带重音的字符é可以是一个单独码点U00E9也可以是字母e后面加一个组合重音符号U0301。它们渲染出来几乎一样但字符串不相等。解决办法是用normalizeconst a é; const b e\u0301; console.log(a b); // false console.log(a.normalize() b.normalize()); // true这种“长得一样却不相等”的问题在英文和法语内容里尤其常见。如果多语言输入来自不同的系统比较之前做一次normalize(NFC)能省掉不少排查时间。4. 字符串长度与编码JS 的length不是你以为的那个“字符数”4.1length数的是 UTF-16 码元不是肉眼字符很多前端初学者看到abc.length 3就以为length是字符数。直到遇到 emojiconsole.log(.length); // 2 console.log(.length); // 2原因是 JS 内部使用 UTF-16 编码像 emoji 这类超出基本平面的字符需要两个码元来表示也就是所谓的代理对。length返回的是码元数量所以看起来是一个字符返回却是 2。如果产品需求是“最多输入 10 个字符”直接用str.length 10判断用户输入几个 emoji 就会出问题。我之前做过一个评论框用户发一个“笑哭”表情就占了两个长度导致他只能打半句话后台还一直报“长度不足”最后改成按字符数计算才解决。正确计算字符数的方法const countChars (str) Array.from(str).length;Array.from能按码点拆分大多数 emoji 都能正确统计。如果需要处理更复杂的组合字符比如这种用零宽连接符拼起来的家庭表情就要用Intl.Segmenterconst countGraphemes (str) [...new Intl.Segmenter(zh, { granularity: grapheme }).segment(str)].length;现代浏览器对Intl.Segmenter的支持已经很好了遇到这种需求只管用。4.2 截断字符串不能简单slice当你要做列表摘要、面包屑截断、标题隐藏时大家都会想到sliceconst str 这是一段测试文本; str.slice(0, 6);问题是slice是按 UTF-16 码元来切的碰到 emoji 很有可能把一个完整的字符切成两半轻则显示成乱码重则导致后续拼接时出现异常字符。稳妥做法是先把字符串按可见字符拆开再截断function safeTruncate(str, max, suffix …) { const chars Array.from(str); const visible chars.slice(0, max); return chars.length max ? visible.join() suffix : str; } console.log(safeTruncate(这是一段测试文本, 5));这个方案对大多数场景够用了。如果是生产环境面对肤色 emoji、组合表情可以用Intl.Segmenter按“用户感知的字符”来切分。总之别无脑slice字符串截断看起来越简单越容易在边界上炸给你看。4.3 字节长度接口不认字符只认字节服务端存储、数据库字段、日志系统很多时候按字节数限制长度。一个中文字符在 UTF-8 下可能占 3 个字节一个 emoji 占 4 个字节。所以不能用str.length当作字节长度。浏览器自带的 API 可以帮你算new TextEncoder().encode(str).length; // 或者 new Blob([str]).size;TextEncoder是标准 API性能不错也不需要额外依赖。如果你在面试里被问到“怎么计算字符串字节数”能说出这个方案比手写一个 UTF-8 编码循环更符合工程思维。还有一个沟通层面的经验产品说“最多 20 字”你要在需求评审时确认这到底是“20 个字符”还是“20 个字节”。很多后端同学会默认按字节校验前端按字符限制两边标准不一致就会出现“前端明明限制了后端依然报长度错误”的尴尬局面。5. 字符串和数组、数字互转每一个方向都有翻车姿势5.1split与join不是互相逆运算split把字符串拆成数组join把数组拼成字符串看起来是一对但细节里全是坑。abc.split(); // [a, b, c] .split(,); // [] 1,2,,.split(,); // [1, 2, , ] [1, 2, null, undefined].join(,); // 1,2,,注意[null, undefined]在join时会变成空字符串这在生成 CSV、接口参数时经常造成数据错位。如果数组元素可能是空值先过滤再 join或者显式转成空串。另外.split()会返回两个乱码字符原因还是代理对的问题。想要按真实字符拆分用Array.from或展开运算符Array.from(ab); // [a, , b]如果你只是按某个分隔符拆分常规字符串split当然没问题。但涉及 emoji 时记得它有这个限制。5.2 字符串转数字parseInt、Number、三兄弟这是面试高频也是实际 bug 高发区。三个核心差异必须记清楚parseInt(123abc)返回123。它会从左到右解析遇到非数字字符就停。Number(123abc)返回NaN。它要求整个字符串都是合法的数字。123abc也返回NaN和Number的行为基本一致。parseInt(0x10)会按十六进制解析返回16因为parseInt支持十六进制前缀。parseInt(08)建议显式传入进制参数10避免老环境下的奇怪解析行为。如果你要解析用户输入的价格、数量建议先校验再转换function toSafeNumber(input) { const num Number(input); return Number.isFinite(num) ? num : 0; }如果保留小数别用parseFloat(str).toFixed(2)走一圈因为toFixed返回的是字符串后面再做数学运算时会得到意外的拼接结果。想要数字结果可以用Number(num.toFixed(2))或者Math.round。5.3 数组转字符串toString只适合简单场景前端经常要把数组传给后端。直接用arr.toString()会默认用逗号连接得到1,2,3。如果数组元素本身含有逗号后端再按逗号拆分时数据就已经损坏了[a,b, c].toString(); // a,b,c语义丢失这种情况下老老实实用JSON.stringify(arr)或者选一个自定义分隔符const ids arr.map((id) String(id)).join(,);另外不要用String(arr)去替代JSON.stringify(arr)序列化对象。String({})会返回字符串[object Object]。别笑我真的见过有人把对象直接拼进 URL 参数后台日志里全是[object Object]排查了半天还以为是接口问题。5.4 大小写转换的 locale 问题toLowerCase和toUpperCase看起来相当无脑但遇到土耳其语等特殊 locale 时会有奇怪行为。比如土耳其语的I小写是ı不带点而不是常见的i。如果你的产品只服务中英文问题不大但如果做成国际化产品就要注意语言环境。Hello.toLocaleLowerCase(tr);这类问题在代码评审里很少被注意到但一旦遇到真实用户会被当成本地化 bug 提过来。那种“明明代码没变怎么国外用户就报错了”的问题很多时候就是这些细节造成的。6. 一些“看起来很猛”的字符串操作其实一写就错6.1 字符串排序别直接sort()中文会很受伤字符串排序是前端面试题里的常客但实际业务里更容易踩坑。先看最经典的[b, a, c].sort(); // [a, b, c] [10, 9, 1].sort(); // [1, 10, 9]字典序不是数字序所以数字字符串排序之前要先转成数字[10, 9, 1].sort((a, b) Number(a) - Number(b));中文排序的问题更大。直接按 Unicode 码点排序得到的结果通常不是我们认知里的拼音顺序。要按拼音排用localeCompare[张三, 李四, 王五].sort((a, b) a.localeCompare(b, zh-Hans-CN));但有一个需要留意的地方localeCompare的结果依赖浏览器或操作系统的 ICU 数据不同环境可能会有细微差异。如果是后端要拿这个顺序去做分页前端展示和接口返回顺序不一致就会让人很崩溃。顺序要求严格时宁可在后端排好前端不要硬扛。6.2 字符串逆序split().reverse().join()对 emoji 不友好经典面试题“反转字符串”最常见答案是const reverseStr (str) str.split().reverse().join();这个解法对 ASCII 没问题对中文也基本没问题但遇到 emoji 就会拆坏因为split()按码元拆分会把代理对切成两半。稍微改进一下const reverseStr (str) Array.from(str).reverse().join();如果还有更复杂的组合字符可以用Intl.Segmenter按用户感知的字符切分然后反转。面试时如果能主动提到Array.from处理 emoji就已经比大多数候选人想得深了一层。6.3 用字符串动态访问对象属性省市区联动的常见 bug做省市区三级联动时接口经常返回const regionData { 110000: { name: 北京市, children: { 110101: { name: 东城区 } } } };前端拿到用户选中的 code然后通过data[code]去取数据。坑在什么地方code 如果是从option的 value 拿的通常是字符串从某个组件拿的可能是数字也可能是undefined。一旦类型对不上data[code]就会返回undefined页面就“有数据却匹配不上”。稳妥写法是显式转字符串const province regionData[String(code)] ?? {};另外如果通过字符串拼接生成 key比如data[province_ code]要确保中间没有多余空格或换行。我见过因为数据源里有不可见字符导致 key 对不上整个联动一直不显示下一级最后一行一行打印 key 才发现问题。这种 bug 非常消耗时间。6.4 从字符串到“可执行代码”的诱惑要克制热词里有“通过字符串调用函数”这确实是前端面试会问的点。但工程实践上我强烈建议用映射表而不是eval或new Function。eval不仅危险还会让调试变得很困难因为代码在运行时才生成断点、报错、堆栈信息全部乱了。const actionMap { login: () doLogin(), logout: () doLogout() }; const action login; const fn actionMap[action]; if (fn) fn();这种写法安全、可读、好调试。面试里考察“通过字符串调用函数”本质上不是让你炫技而是看你知道不知道反射式调用的风险和替代方案。7. 问题排查与自查清单把这些刻进肌肉记忆7.1 常见问题速查表这里整理一份我平时 code review 会对照的速查表基本覆盖了上文的大部分坑。场景反面教材推荐做法判断包含str.indexOf(x) -1str.includes(x)URL 参数拼中文直接拼接URLSearchParams或encodeURIComponent字符长度str.length限制用户输入Array.from(str).length或Intl.Segmenter截断字符串str.slice(0, 10)直接截先按可见字符拆分再截断字符串转数字parseInt(123px)当合法数字Number(str)并Number.isFinite校验数组转字符串传后端arr.toString()明确分隔符或 JSON 序列化比较 idif (id 123)统一String(id) String(123)用户输入做正则new RegExp(keyword)先转义或直接用includes中文排序[中,文].sort()localeCompare字符串反转str.split().reverse().join()Array.from(str).reverse().join()表格里的每一行都是我在真实项目里见到过的 bug 原型。你不需要把每个 API 都背下来但看到这些关键词时脑子里要能立刻弹出“这里可能会炸”的警报。7.2 提交代码前花三分钟检查字符串我自己的流程是写完涉及字符串的代码后问自己四个问题。第一这个变量的值可能是null或undefined吗如果是有没有兜底第二这个字符串是给用户看的还是给后端传的给用户看有没有转义给后端传有没有编码第三这个长度是字符数还是字节数产品到底要哪个第四这段字符串操作经得起 emoji、中英文混排、全角半角的考验吗这几个问题问完十个 bug 能提前杀掉八个。特别是第一和第二个问题几乎覆盖了线上问题的两大来源空值和编码。7.3 面试官考察字符串时重点从来不是 API最后补充一点个人观察。前端面试题里经常出现“js 判断字符串是否包含”“字符串排序”这类题目本质上是在看“你有没有把字符串当成一个有编码、有不可变性、有隐式转换风险的数据类型来理解”。背一堆 API 名不如现场说出一句“JS 字符串是 UTF-16 码元的序列所以 length 不等于用户感知的字符数”这句话比背五个方法都更能打动面试官。项目开发也是一样真正让你加班改 bug 的往往不是没记住某个方法而是没搞懂字符串在引擎、网络、展示这三层里的真实形态。把这些底层约束吃透很多 bug 从一开始就不会发生。我个人的体会是想写少 bug 的前端不需要记住所有字符串 API但一定要理解“一个字符串从哪里来、要到哪里去、中间经过了什么转换”。把这条线理清楚你的代码评审通过率会比别人高一大截。
