密钥格式化这道题我最早是在刷题平台上遇到的后来又在好几个后端和全栈的面试题单里看到它的变体。它的英文名是 License Key Formatting题面给一个混合了字母、数字和短横线的字符串 S 和一个正整数 K要求把 S 重新格式化先剔除所有短横线把字母全部转成大写再按照每 K 个字符一组用短横线分隔。最容易被忽略的点是这里的分组不是从左往右均匀切而是从字符串的尾部开始切只有最左边的一组可以少于 K 个字符。很多人在这一条上翻车。这篇文章我把 Java、JS、Python 三个版本的实现都完整写一遍并把我调试时踩过的坑、自测的用例、面试的回答思路一起整理出来供同样被这道题折磨过的朋友参考。1. 题目到底在考什么先把这个密钥格式化的规则锁死1.1 从题目描述拆出来的三个硬性规则密钥格式化的输入非常直白比如5F3Z-2e-9-w和K4期望输出是5F3Z-2E9W输入2-5g-3-J、K2期望输出是2-5G-3J。只看这两个例子你可能觉得规则很清晰。真正动手写的时候容易忽略三点第一原始字符串里可以出现多个连续的短横线也可能在开头结尾出现清洗时不能只去掉单个横杠必须把全部-忽略掉。比如--A--b-c---清洗后就是ABC不是A-B-C也不是保留原横杠。第二字母要转大写题目通常不区分大小写敏感但输出必须是统一大写。在 Java 里可以用Character.toUpperCase在 JS/Python 里也有现成的toUpperCase/upper方法数字则原样保留。第三分组方向是“从右往左”。不能简单地把清洗后的字符串按每 K 个字符从左边切开不够 K 个的那一组只能出现在最左边不能在右边。这个第三点就是整道题的分水岭。很多人会下意识地从左往右按 K 个字符切最后一段不足 K 个结果完全不符合题目要求。在面试里面试官往往就盯住这一条看你有没有仔细读题。1.2 为什么“从右往左分组”是最不容易错的思考方式如果从左往右每 K 个切一段当最后一段长度不足 K 时结果就会变成末尾短组。比如25G3J, K2按左切是25-G3-J但标准答案是2-5G-3J。原因很简单题目要求“最后一组必须满 K 个”短组只能出现在开头。怎么保证“最后一组满 K 个”这里有两种主流思路。思路 A先算出清洗后的长度 n用n % K得到第一组长度余数为 0 时第一组长度就是 K之后按 K 步进切分。这是 Python 版使用的方式也最符合题目描述的数学关系。思路 B直接倒序遍历原始字符串从右往左收集字符每收集满 K 个字符就形成一个组最后把整体反过来。Java 版通常用这种方式优点是天然贴合规则不需要先算余数。这两种思路都可以但要避免不伦不类的中间写法从左往右遍历却用一个count去找“从哪截断”。那种写法往往会把横杠位置算错。我个人认为“从右往左”更不容易出错因为它是把规则直接翻译成代码而不是先翻译成求余公式。尤其是 K 比较小、字符串比较短的时候倒序的每一组对应什么内容一目了然。1.3 不管哪种实现复杂度都逃不出 O(n)做这道题时我会在面试中主动把复杂度说清楚对每个字符只扫描一次时间是 O(n)这里的 n 是输入字符串的有效长度加上原始短横线也是 O(N)。空间上因为要构造新的输出字符串至少要 O(n)Java 如果再算上 StringBuilder 底层数组也是 O(n)。JS 的数组切片、Python 的列表和 join同样会额外占用 O(n) 内存。所以这道题不存在 O(1) 空间的纯字符串输出方案除非你能原地修改字符数组并利用原有字符串的剩余空间但主流语言一般不这么干。在面试里说完复杂度后我还会补一句如果输入是链表形式的字符流或者超长字符串就不建议用StringBuilder.reverse()这种需要整体反转的方法而是用显式栈或双端队列先把短组挂在队头。这个问题可以作为追问点后面在扩展部分单独展开。2. 用 Java 实现StringBuilder 倒序遍历的经典组合2.1 Java 版代码与逐行注释先直接给可以跑的版本public String licenseKeyFormatting(String s, int k) { StringBuilder sb new StringBuilder(); int count 0; for (int i s.length() - 1; i 0; i--) { char c s.charAt(i); if (c -) { continue; } if (count k) { sb.append(-); count 0; } if (c a c z) { c (char) (c - 32); } sb.append(c); count; } return sb.reverse().toString(); }这里的关键是每当要追加一个新字符之前先看已经收集了多少个字符如果已经有 k 个就先补一个-再清空计数。这样做的好处是短横线永远不会追加到最终字符串的末尾因为只有当后面还有新字符时才补横杠。循环结束后sb里的内容是倒序的短组顺序所以最后一步reverse。例如清洗后是25G3J, K2倒序遍历收集顺序是J、3组成一组然后是G、5最后2单独一组构建出来的sb内容大致是J3-G5-2reverse 后得到2-5G-3J完全正确。这就是倒序加反转的精髓不需要手动计算n % k。2.2 两个必踩的坑末尾横杠处理与字符转换第一个坑是“先加横杠后删除”的错误写法。很多人习惯写成if (count k) { sb.append(c); sb.append(-); count 0; }在倒序遍历时这会让最后一个组的末尾带上-最后 reverse 后-跑到字符串开头。比如刚才的例子会得到-2-5G-3J这种非法输出。所以要么在 append 字符前判断并补横杠要么在 reverse 前把末尾的-删掉。我推荐前者逻辑更干净也少一次deleteCharAt操作。第二个坑是大小写转换。Java 的Character.toUpperCase(c)能处理 Unicode但这个场景里字符只可能是 ASCII 字母或数字完全可以用if (c a c z) c - 32。注意这行需要强制类型转换因为char参与算术运算后自动变成 intif (c a c z) { c (char) (c - 32); }虽然Character.toUpperCase可读性更好但它每次调用都有方法调用开销。在面试中我会先写可读版本再提一句可以用 ASCII 运算优化这样反而能体现对细节的把握。字符串拼接是第三个坑千万不要写result sb.charAt(...) result这种循环头插Java 字符串不可变头插的复杂度是 O(n^2)。用StringBuilder的目的就是避免这个。2.3 如果不用 StringBuilder还能怎么写还有一个思路是先正序遍历清洗后的字符串把它拆分成若干组。Java 里可以用split或者Matcher但需要正则表达式不如倒序直观。这里给出一个与 Python 思路对齐的版本public String licenseKeyFormatting(String s, int k) { String cleaned s.replace(-, ).toUpperCase(); if (cleaned.isEmpty()) { return ; } StringBuilder result new StringBuilder(); int head cleaned.length() % k; if (head 0) { result.append(cleaned, 0, head); } for (int i head; i cleaned.length(); i k) { if (result.length() 0) { result.append(-); } result.append(cleaned, i, Math.min(cleaned.length(), i k)); } return result.toString(); }这个版本的好处是避免了最后的 reverse直接按照“短组开头”的顺序拼接。它的逻辑更接近 Python 版适合在面试中和倒序版对比。我个人更推荐熟练掌握一种主思路另一种作为补充不要每个版本都背。面试时能解释清楚你选的那个方案为什么不会在头尾产生横杠就足够了。3. 用 JavaScript 实现正则清洗 切片分组思路完全不同3.1 JS 版代码先用正则清掉横杠再从后往前切JavaScript 版本可以完全换一种节奏先清洗再从后往前按 K 个字符切片function licenseKeyFormatting(s, k) { const clean s.replace(/-/g, ).toUpperCase(); const parts []; for (let i clean.length; i 0; i - k) { const start Math.max(0, i - k); parts.push(clean.slice(start, i)); } return parts.reverse().join(-); }这里s.replace(/-/g, )用来删除所有短横线toUpperCase()统一大写。循环从clean.length开始每次向前推进 K 个字符i表示当前切片的右边界start Math.max(0, i - k)保证左侧不会越界。比如clean 25G3J, k2第一轮i5切片[3,5)得到3J第二轮i3切片[1,3)得到5G第三轮i1切片[0,1)得到2。此时parts [3J, 5G, 2]reverse 后变成[2, 5G, 3J]join 得到2-5G-3J。整个过程没有产生多余的横杠因为join(-)只在数组元素之间加分隔符数组里的每个元素正好是一个非空组。这个写法非常符合 JS 的函数式风格也是我在前端实际项目中偏好的写法。3.2 为什么用数组 push而不是字符串拼接有些同学看到这个逻辑会写let result ; for (let i clean.length; i 0; i - k) { result clean.slice(Math.max(0, i - k), i) (result ? - result : ); } return result;这个写法结果也对但每轮都用生成新字符串。JS 字符串也是不可变的循环次数多时会产生大量临时字符串造成不必要的 GC 压力。虽然这道题的输入规模一般压不死人但我写业务代码时习惯先parts.push最后join因为数组的 slice 和 join 在 V8 里有成熟优化比反复拼接稳定。尤其当 K1 时分组数等于字符串长度拼接法的临时对象会翻倍。如果你想更“正则”一点也可以这样function licenseKeyFormatting(s, k) { const clean s.replace(/-/g, ).toUpperCase(); return clean.match(new RegExp(.{1,${k}}, g))?.join(-) ?? ; }但这个写法只能从左往右分组当最后一段不足 K 时它会把短组放在末尾结果不符合题意。要改成从右往左需要先计算余数正则写起来非常晦涩。所以我的建议是正则只用于清洗分组交给循环切片别硬着头皮用正则表达“从右往左”这种语义。3.3 一个容易被误以为正确的写法按 K 从头分组错在哪如果 JS 面试官让你现场写很多人会写出下面的版本function licenseKeyFormatting(s, k) { const clean s.replace(/-/g, ).toUpperCase(); const parts []; for (let i 0; i clean.length; i k) { parts.push(clean.slice(i, i k)); } return parts.join(-); }这种写法错在把短组放到了最后。比如2-5g-3-J, k2清洗后是25G3J从左往右切片得到[25, G3, J]输出25-G3-J而题目要求2-5G-3J。所以这题在面试里特别适合考察候选人有没有认真读“分组从尾部开始”这个条件。调整的方法很简单先算head clean.length % k如果 head 大于 0先切一截 head 长度的前缀再循环切后面长度为 k 的组。不过这样代码会稍微长一些不如倒序切片版本简洁。在实际面试中如果候选人写出从左往右切分的版本我通常会提示一句“最后一组不足 K 了但题目的意思是只有第一组可以不足 K”看他能不能立刻调整方向。能快速反应过来的说明他对边界条件的敏感度不错。4. 用 Python 实现三分钟写出来的极简版4.1 Python 版代码利用取模确定第一组长度Python 的字符串方法天然适合这种清洗工作def license_key_formatting(s: str, k: int) - str: cleaned s.replace(-, ).upper() n len(cleaned) if n 0: return head n % k parts [] if head 0: parts.append(cleaned[:head]) for i in range(head, n, k): parts.append(cleaned[i:i k]) return -.join(parts)清洗用replace(-, )一次清掉所有短横线比正则还省心upper()直接转大写。然后计算head n % k这个head表示最左侧短组的长度。比如n5, k2head 是 1所以第一组取cleaned[:1]得到2后续从下标 1 开始每隔 2 个取一组得到5G和3J最后用短横线连接。如果n正好是k的倍数比如n8, k4head 为 0直接跳过第一组分支从下标 0 开始每隔 4 取一组每组长度都相等输出自然正确。这个解法的时间复杂度是 O(n)空间复杂度是 O(n)。编码时唯一要小心的就是head为 0 的情况跳过那行append否则会把空字符串也当作一组join 之后会产生多余的连字符。4.2 Python 的切片和 join 有多适合这道题如果你经常用 Python 刷题会发现这道题几乎是“为 Python 量身定做”的replace清洗、upper转大写、切片分组、join连接每一步都是 O(n) 的常见操作代码读起来像题目描述的翻译不需要额外处理StringBuilder反转这种底层细节。另外Python 有一个小特性切片不会越界。比如cleaned[i:ik]哪怕最后不足 k 个字符也会安全地返回剩余部分。但这里因为我们用head固定了首组长度后面每组都会恰好取到 k 个所以并不需要依赖这个特性。假如从左往右直接range(0, n, k)切片就会得到末尾短组所以还是要先算余数。我还见过用textwrap.wrap的写法import textwrap def license_key_formatting(s, k): cleaned s.replace(-, ).upper() return -.join(textwrap.wrap(cleaned, k))这个写法看起来一行完成但textwrap.wrap是从左往右切依然会把短组放末尾直接输出25-G3-J。除非先用cleaned补零让长度能被 K 整除再处理前导零否则不可行。所以刷题时别为了“少写两行”引入一个语义不对的库函数。4.3 当输入全是短横线时Python 为什么不会翻车有些人对---这种输入很慌以为要么返回-要么直接抛异常。实际上在 Python 版里cleaned会变成空字符串n0提前返回如果没写提前返回head0parts[]-.join([])也会得到空字符串。所以不管写不写if n 0结果都不容易错。但我仍然建议显式处理。第一语义清楚代码审查者一眼能看到边界条件被考虑过了第二避免有人后续在parts.append分支里做parts[-1]之类的操作时崩溃第三面试时主动提这个边界会加分。类似地如果输入是空字符串也会走同一分支。这些都是字符串处理题必须考虑的空输入场景。加一个显式判断成本很低不要省。5. 边界条件与自测用例把易错点变成测试集5.1 我自己常用的十组测试用例刷题光把代码写完不算完我会把下面这些用例在本地或 LeetCode 上跑一遍。它们分别覆盖基本分组、头部短组、整除情况、空串、全横杠、K 大于长度、全是数字、多个连续横杠、单字符输入和 K1 的极端情况。用例SK期望输出覆盖点15F3Z-2e-9-w45F3Z-2E9W官方样例大小写混排22-5g-3-J22-5G-3J官方样例头部短组3a-b-c1A-B-CK1每组一个字符4a2AK 大于单字符长度55空输入6---3清洗后为空7abc10ABCK 比有效长度大无横杠8123-456-7893123-456-789全数字长度整除9--A--b-c---2A-BC多个连续横杠头部短组10ab--cd--e3AB-CDE多个连续横杠且头部短组其中第 9 行我特别提一下--A--b-c---清洗后是ABC长度 3K2头部短组长度 1所以输出A-BC。这个用例很容易被误写成AB-C是检验“从右往左分组”是否理解到位的好题目。5.2 从“过样例”到“过全部”的排查顺序如果测试用例失败我一般按下面的顺序排查先看清洗后的字符串有没有残留短横线是不是所有字母都大写了再看分组数量用len(cleaned) % k算出预期首组长度对照实际输出首组长度。检查输出两端有没有多余短横线尤其是 Java 反转版本的-位置。最后检查k1和k n这两个极端分支。这里可以给出一段 Python 自测代码读者可以直接跑cases [ (5F3Z-2e-9-w, 4, 5F3Z-2E9W), (2-5g-3-J, 2, 2-5G-3J), (a-b-c, 1, A-B-C), (a, 2, A), (, 5, ), (---, 3, ), (abc, 10, ABC), (123-456-789, 3, 123-456-789), (--A--b-c---, 2, A-BC), (ab--cd--e, 3, AB-CDE), ] for s, k, expected in cases: result license_key_formatting(s, k) assert result expected, f{s}, k{k}: got {result}, expected {expected} print(all passed)Java 和 JS 同理可以写到main或 Node 脚本里。我特别建议把官方两个样例之外的边界也放进去因为面试现场经常有人为了快点提交只过了两个样例就交卷结果挂在空串或全横杠上。多花一分钟跑完这组用例能避免很多低级失误。6. Java、JS、Python 三版实现的对比与面试拓展6.1 三版代码的复杂度与实现风格对比语言核心思路时间复杂度空间复杂度最需要注意的点JavaStringBuilder 倒序 reverseO(n)O(n)反转顺序横杠位置JS正则清洗 倒序切片 joinO(n)O(n)别从左往右直接切Pythonreplace/upper 取模首组 joinO(n)O(n)head 为 0 时别 append 空串这三个版本分别代表了三种风格Java 偏底层需要手动管理拼接过程JS 靠数组和正则的配合代码最简短Python 则把字符串处理当成“组合拳”读起来像伪代码。在面试中能按这种维度对比比只背一个版本更有说服力。如果你被问到“为什么不用正则一次搞定”可以回答正则适合清洗不适合反向分组分组逻辑用循环或切片表达更清晰也更好维护。6.2 面试官追问如果 K 很大或者字符串是流式输入怎么办当 K 大于清洗后的长度时代码自然会输出一个无横杠的大写字符串。这里可以提前做一次快速返回例如 Python 里写if n k: return cleaned能省掉构建列表的过程。虽然时间复杂度不变但是在真实超长字符串场景下可以减少一次join的消耗。如果面试官继续追问“如果流式接收字符内存有限不能把全部字符缓存下来怎么办”那么原来的倒序法就不成立了。一个折中方案是先记录已经收到的有效字符总数并以 K 为周期切组同时用一个小的循环数组保存当前组内容当组满 K 个时立刻输出一组但需要在最后处理头部短组。更好的方式是用双端队列把短组保留到开头。实际上这道题考察的是字符串处理不是流处理。面试官这么问更多是看你有没有意识去分析场景差异。你可以给一个方案维护一个容量为 K 的缓冲区每次来新字符就压入并计数缓冲区满时把整组推入结果列表结束后如果缓冲区还有内容这一组需要放到最终输出的最前面而不是最后面。能把这个流程说清楚说明你对“短组在头部”这个规则是真的理解了而不是背代码。6.3 这个格式化逻辑在真实业务里还能怎么用除了刷题密钥格式化也是不少系统设计里的小工具。最常见的场景是激活码、兑换码和产品密钥的显示规整比如取一个随机生成的 32 位字符串用这道题的逻辑每隔 8 位加一个横杠输出成ABCDEFGH-...。另一个场景是日志脱敏把密钥的中后段打码只保留前后若干位本质上是对格式化后的分组做掩码处理。我做过一个内部工具输入是一长串十六进制的硬件指纹输出按 8 位分组的可读序列号。最初直接每 8 位切一刀后来发现新规则也要求“不足 8 位的放最前”跟这道题一模一样。那时候我就意识到这个看似小学难度的格式化逻辑真的在真实代码里反复出现。所以把它吃透不只是为了面试。如果业务中需要同时兼容多种格式可以抽一个公共函数public static String formatKey(String raw, int blockSize) { // 清洗、大写、从右往左分组 }这样上层调用方不用关心分组细节后续要改成全小写分组也只需要改一个方法。7. 刷题之外的几点体会7.1 字符串题先画一条时间线再写代码我在刷字符串类题目时有个习惯先拿一个小样例在纸上画一遍流程标清楚每个变量在每次循环后的值。密钥格式化这道题尤其值得画因为它的关键不在算法复杂度而在“什么时候加横杠、什么时候反转”。一旦你把count和sb的状态画出来代码自然就顺了。很多人在白板上卡壳不是不会语法而是心里没有一张状态图。面试时如果允许直接在纸上画abc, k2这个例子比干讲更清楚清洗后是ABCK2。倒序遍历构建倒序分组先取BC剩下A作为头部短组所以结果是A-BC。这个过程用三行手写就能说清楚。7.2 三种语言建议至少掌握两种写法如果有人问我刷题用什么语言我会说至少准备两种一种是你主力面试语言一种是你日常写业务的脚本语言。比如主力 Java辅助 Python。密钥格式化这种题用 Python 先验证思路再用 Java 写最终答案效率很高。JS 则适合前端岗位单独考察或者在后端面试里作为“你会不会别的语言”的加分项。但要注意不要为了一味追求“代码最短”而牺牲可读性。我在 Python 版里没有用textwrap.wrap在 JS 版里也没有用复杂的正则分组都是因为那些写法要么方向错误要么对阅读者不友好。达到目的、边界清晰、复杂度正确比“一行流”更重要。7.3 最终建议把这道题变成你的模板题很多字符串处理题都有相似套路清洗 - 变换 - 分组/反转 - 拼接。密钥格式化正好把这个套路走完整。你只要抽象出四个步骤就能迁移到脱敏、序列号格式化、URL 拼接等场景。平时我会把这类题归类到“字符串清洗与分组模板”里每过一段时间重写一遍不是为了背答案而是为了保持对边界条件的敏感。我个人的建议是在 LeetCode 上把这题标记为 Easy 和 Medium 之间然后分别用三种语言各提交一次每次检查提交记录里的运行时间和内存。你会发现 Java 版通常内存稍高Python 版代码最短JS 版折中。理解这些差异面试时被问到“你平时怎么选型”也能有真实依据。最后再分享一个我踩过的坑有一段时间我习惯把所有字符串题都先toLowerCase再处理导致密钥格式化里的大写字母被错误转换。后来我把“原样保留、只清洗、按需求转换”这个顺序固定下来类似的低级错误就再没犯过。