“字典序”这个词，很多人在大学数据结构课上第一次听到时，都以为是要去背一个字典。我最近整理了一个叫“WHAT - 字典序”的小项目，本质就是想用最直白的方式，把这三个字彻底讲透：它是什么、为什么程序里到处都是它、怎么用它解决实际问题、以及它到底藏了多少坑。如果你刷算法题、写业务代码，或者只是好奇为什么"apple"永远排在"banana"前面，这篇可以帮你少走不少弯路。
1. 字典序到底是什么：从查单词的直觉到严谨定义
1.1 先把“按字母排”这件事讲清楚
字典序，英文是 lexicographical order，也叫字典顺序、字母顺序。它的直觉来源就是英语词典：打开一本纸质词典，apple一定在banana前面，因为先比较第一个字母，a排在b前面。如果第一个字母相同，就继续比第二个字母。比如apply和apple，前三个字符都是a p p，第四个字就分出了胜负：l和l相同继续，第五个字符e和y不同，e排在y前面，所以apple在前。
这套规则一旦落到字符串上，就是计算机世界的“词典排序”。所有编程语言里，字符串比较的默认行为，基本都是字典序。Java 里是String.compareTo()，C++ 里是std::string的operator<，JavaScript 里用<或者>比较字符串，Python 里直接用<也能比较字符串。它们遵循的都是同一套逐字符比较的规律。
但这里有个关键细节：当比较进行到其中一个字符串结束，而另一个字符串还有剩余字符时，怎么办？规则是：短的串排在前面。比如"abc"和"abcd"，比较完a b c后，第一个串到头了，那"abc"就比"abcd"小。这条规则非常重要，很多人写排序、写去重时在这里栽过跟头，后面我会专门展开。
1.2 为什么这个“古老”的规则今天依然无处不在
有人可能会问：现在都什么年代了，为什么我们排序、查找还要依赖一个从纸质词典时代流传下来的规则？
答案很简单：因为字典序满足“全序关系”。数学上，全序关系要求任意两个元素都可以比较大小，且比较关系满足传递性。字典序天然满足这两点：任意两个字符串，从头比较，总能在有限步内分出大小；如果a排在b前，b排在c前，那a一定排在c前。这意味着，你可以把所有字符串排成一条唯一确定的序列，这就是排序算法的前提。
另外，字典序比较的成本很低。最坏情况下需要比较两个字符串长度的最小值次数，但平均场景下，通常比较几个字符就能出结果。相比数值排序需要解析整个数字，字典序的逐字符比较在很多场景下反而更轻快。比如在分布式系统的路由表、键值存储的 key 排序、数据库索引的维护里，需要频繁比较字符串，字典序就是那个既稳定又高效的基础设施。
还有一个很重要的原因：字典序和“前缀”关系天然绑定。同一个前缀的字符串在字典序下会连续排在一起，这直接决定了 Trie 树（前缀树）的遍历顺序、自动补全的候选词顺序，以及字符串集合的分桶策略。可以说，想懂字符串相关的数据结构和算法，字典序就是地基里的地基。
2. 字典序核心规则拆解：字符顺序到底由谁决定
2.1 三条铁律：逐字符、比码点、短在前
先来一个无编程基础也能看懂的拆解。假设有两个字符串 A 和 B，比较过程遵循三条铁律。
第一，从 A 和 B 的第一个字符开始，一个一个对应着比。第二，一旦发现某个位置上的字符不同，直接按这对字符的顺序决定胜负，后面不用再看了。第三，如果其中一个串已经结束，另一个还没结束，那么已经结束的短串更小。
举个例子，比较"abc"和"abd"。第一位a等于a，第二位b等于b，第三位c和d不同，c比d小，所以"abc"小于"abd"。整个过程只比较了三次。再比较"abc"和"abcd"。前三位完全相同，第一个串结束，根据第三条铁律，"abc"小于"abcd"。
这套逻辑落到代码里，就是一个非常清晰的双指针循环。比如用 JavaScript 手写一个比较函数：
function compareLex(a, b) { const lenA = a.length; const lenB = b.length; const minLen = Math.min(lenA, lenB); for (let i = 0; i < minLen; i++) { const ca = a.charCodeAt(i); const cb = b.charCodeAt(i); if (ca !== cb) { return ca - cb; } } return lenA - lenB; }返回值是负数，说明a排在b前面；返回值是正数，说明a排在b后面；返回 0 说明两个字符串相等。ca - cb这个减法，本质上就是用字符的数值差来判断字符大小，因为计算机底层拿到的根本不是“字母”，而是数字编码。
2.2 字符顺序的真正裁判：ASCII 码与 Unicode 码点
这样就引出第二个关键问题：字符比较的“大小”由谁决定？答案是码点（code point）。在 ASCII 时代，规则非常简单明确，'0'到'9'对应 48 到 57，'A'到'Z'对应 65 到 90，'a'到'z'对应 97 到 122。所以在 ASCII 码表里，数字字符小于大写字母，大写字母小于小写字母。于是有了一个经典反直觉现象："Z"比"a"小，因为'Z'的码点 90 小于'a'的码点 97。
在 Unicode 时代，情况变得更复杂。汉字等非拉丁字符也有自己的码点，但码点的数值顺序和拼音一点关系都没有。比如"一"、"丁"、"七"三个汉字，按 Unicode 码点排序的结果，和按拼音排序的结果、按笔画排序的结果可能是完全不同的。
这一点直接影响业务。数据库里做ORDER BY时，如果不指定 collation（排序规则），MySQL 默认用的是 utf8mb4 下的二进制约束排序，对中文字段排序的结果大概率是“看起来没有规律”的码点顺序，而不是用户期望的拼音顺序。很多初入行的开发者在做中文字段排序时满脸疑惑，根因就在这里。
2.3 一个容易被忽略的东西：大小写与空格
字典序还有一个“隐藏玩家”：空白字符。空格在 ASCII 表里是 32，比数字、字母都小。这意味着"a b"可以直接排到"ab"前面，因为比较到第二个字符时，空格（32）小于'b'（98）。同理，"abc "（尾部带空格）会排在"abc"前面，因为三个字符比较完后，前一个串还剩下一个空格，和已经结束的短串比较时，空格的存在让长串变得“更大”，所以短串在前。
至于大小写，不同语言的默认行为还不一样。Java 的compareTo是按码点严格比较，区分大小写；JavaScript 的<也是区分大小写的；但 Python 的字符串比较同样区分大小写。如果业务里需要忽略大小写，Java 用compareToIgnoreCase，JS 得先把字符串转成同一种 case 再比较。这里没有统一的“正确”答案，只有明确的业务约定。
3. 为什么字典序能成为编程题的“标准答案”逻辑
3.1 全序关系带来的工程确定性
我在“WHAT - 字典序”这个项目里，专门把“为什么用字典序”和“字典序是什么”拆成了两个章节。因为只懂规则而不懂动机，遇到题目还是不知道怎么选。
字典序最大的工程优势是确定性。同样一组字符串，用字典序排序，任何人在任何机器上跑，结果都是一样的。这种确定性让它可以作为分布式系统中的基准：多个节点要对同一批 key 做排序，不需要协商算法，直接用字典序，结果天然一致。在 Paxos、Raft 这些一致性协议中，日志条目要按某种顺序排列，字典序就是最朴素的“公共语言”。
第二个优势是直观性。字典序的结果和日常查词典的预期一致，调试起来心智负担小。你让产品经理验证一个排序功能，他看到apple < banana < pear会觉得合理；如果看到pear < apple < banana，第一反应就是 bug。
第三个优势是遍历顺序的一致性。在 DFS 回溯算法里，如果每一步都按字符或数字本身的升序尝试，最终生成的排列、组合天然就是字典序的。这个性质被大量算法题直接利用：要求“按字典序输出所有排列”时，只要初始数组升序，然后反复调用“下一个排列”，就可以按字典序全量输出，不需要最后加一次排序。
3.2 一网打尽：字典序的经典应用清单
把字典序当成一个“工具”，它的应用场景其实横跨算法、存储、协议、日常业务。我按工程频率从高到低列一份：
第一，字符串排序与去重。任何ORDER BY、任何sort()，只要不指定自定义比较器，底层都在用字典序。数据去重时，先按字典序排序，再比较相邻元素，是最经典也最省内存的做法。
第二，字典序全排列与组合输出。LeetCode 第 46 题、第 47 题、第 78 题，以及“下一个排列”第 31 题，全部围绕字典序展开。甚至 C++ STL 里的next_permutation函数，内部实现就是基于字典序的“下一个更大序列”算法。
第三，前缀匹配与自动补全。Trie 树中按字典序遍历子树，得到的单词列表就是字典序的自动补全候选。输入法、IDE、搜索引擎的搜索建议，背后都有这个逻辑。
第四，版本号比较与协议字段排序。版本号虽然长得像数字，但很多系统为了兼容非法格式，选择用字符串存储。字符串比较版本号会掉进陷阱，于是“分段后逐段按数值比较”成了通用方案，而分段的比较顺序依然沿用字典序逐段推进的框架。
第五，字符串 key 有序存储。Redis 的 ZSET、LevelDB 的 SSTable、MySQL 的索引用到有序结构时，都依赖可以比较大小的 key，字符串 key 的默认比较准则就是字典序。
4. 实操一：5 分钟手写一套可用的字典序比较逻辑
4.1 自己写 vs 用标准库：什么场景需要手写
很多刚接触的人会问：语言不是自带比较吗，为什么还要手写？
因为标准库的默认行为未必符合业务需求。比如 JavaScript 的Array.sort()，如果不传比较函数，会把元素先转成字符串，再按字典序比较。这导致[2, 10, 1]被排成[1, 10, 2]，而不是[1, 2, 10]。这不是 bug，这就是字典序的默认行为，但不写数字排序的人往往会懵一下。另一个常见场景是版本号排序、自定义对象排序。你有一个对象数组，要根据某个字符串字段做排序，此时需要告诉排序函数“按字典序比较该字段”，很多情况下还得顺手处理空值、大小写。
手写一套字典序比较器的意义，不在于替代标准库，而在于让你精确控制“字符怎么比”。比如忽略大小写、按拼音、按指定的字符表顺序、遇到数字时按数值处理。这些需求的标准库都不一定直接支持。
4.2 一个可复用的“可配置”比较器模板
下面的代码实现了一个支持两种选项的字典序比较器：是否忽略大小写、是否在遇到连续数字时按数值比较。这个模板可以直接用到实际项目里。
function buildLexCompare({ ignoreCase = false, numeric = false } = {}) { return function (a, b) { const ca = ignoreCase ? a.toLowerCase() : a; const cb = ignoreCase ? b.toLowerCase() : b; if (!numeric) { return ca < cb ? -1 : ca > cb ? 1 : 0; } // 数值模式：把连续的 digit 拆出来当成一个整数比较 let i = 0, j = 0; while (i < ca.length && j < cb.length) { const ia = /\d/.test(ca[i]); const ib = /\d/.test(cb[j]); if (ia && ib) { // 提取完整的数字串 let sa = '', sb = ''; while (i < ca.length && /\d/.test(ca[i])) sa += ca[i++]; while (j < cb.length && /\d/.test(cb[j])) sb += cb[j++]; const na = parseInt(sa, 10); const nb = parseInt(sb, 10); if (na !== nb) return na - nb; } else if (ia !== ib) { return ia ? 1 : -1; // 一个位置数字与非数字比，约定数字排前或排后由你决定 } else { if (ca[i] !== cb[j]) return ca[i] < cb[j] ? -1 : 1; i++; j++; } } if (i < ca.length) return 1; if (j < cb.length) return -1; return 0; }; }这个模板的灵魂在于：把“字符比较”和“整体比较”都收拢到一个函数里，后续要改规则，只改这一个地方。实际业务中，比完大小写、空值，再交给它做逐字比较，整个排序逻辑会非常清晰。
4.3 Java、Python、C++ 中现成的字典序“姿势”
各语言标准库的字符串比较，本质都是字典序，但 API 细节值得区别对待。
Java 中，String.compareTo()按 UTF-16 码元比较，区分大小写。compareToIgnoreCase()忽略大小写。要按“字典序但不区分区位”的另一种路径，可以配合Collator类做本地化排序。
Python 中，字符串的直接<、>就是按 Unicode 码点比较。sorted(['banana', 'apple', 'pear'])默认就是字典序。注意 Python 3 里不能混着比较字符串和数字，否则直接抛TypeError，这也是出于“不让字典序和数值序意外混淆”的设计考量。
C++ 中，std::string的operator<是字典序。标准库里的std::lexicographical_compare可以直接比较两个容器元素，可以作用于vector<int>、list<char>等，规则完全一致。
5. 实操二：字典序实战，从排序、去重到全排列
5.1 给版本号排序：一个字典序的经典陷阱
我相信每个做过发布系统的工程师都踩过这个坑：有一个版本号数组，比如["1.10.0", "1.9.0", "1.2.0"]，想排成["1.2.0", "1.9.0", "1.10.0"]，但用字符串默认排序，得到的结果是["1.10.0", "1.2.0", "1.9.0"]。
原因非常直接：字符串比较到1.之后，第二位分别是1、9、2，ASCII 码里'1'小于'2'小于'9'，所以"1.10.0"排最前面。字符串不知道10大于9，它只认“字符”。
解决办法是分段转数值。先按.拆开，每一段用Number()转成数值，再按从左到右的顺序逐段比较。比较框架依然沿用字典序的“逐位推进”思想，但每一段的比较从字符序换成了数值序。
function compareVersion(a, b) { const arrA = a.split('.').map(Number); const arrB = b.split('.').map(Number); const maxLen = Math.max(arrA.length, arrB.length); for (let i = 0; i < maxLen; i++) { const numA = arrA[i] || 0; // 位数不够补 0 const numB = arrB[i] || 0; if (numA !== numB) return numA - numB; } return 0; } const versions = ["1.10.0", "1.9.0", "1.2.0"]; versions.sort(compareVersion); console.log(versions); // ["1.2.0", "1.9.0", "1.10.0"]这个例子说明了一个通用原则：不要想当然地把“长得像数字”的字符串当数字来排。要么显式转数值，要么明确接受字典序的结果。二选一，别让它悬着。
5.2 字符串数组去重的三种姿势
字符串去重看起来简单，其实也分场景。如果数组无序，最常见的是用 Set 或哈希表去重，时间复杂度 O(n)，不要求输出顺序。但如果题目要求“按字典序输出去重后的结果”，优先顺序就变了。
第一种做法：先排序，再去重。排序之后相同的字符串相邻，遍历时只要和上一个元素比一次，不同才保留。这在内存受限、不能开额外集合的场景下很有用。第二种做法：直接构建有序结构，比如 TreeSet（Java）、sortedcontainers（Python），插入的时候自动维护字典序，最后输出就是有序去重后的结果。第三种做法：如果你用的语言支持链式操作，比如 Kotlin 的.sorted().distinct()，那其实也是“先排序再去重”的语法糖，底层一样。
三种姿势的取舍依据只有一个：能不能容忍排序的额外时间开销。不能容忍并且不要求顺序，就用哈希；要求顺序，排序再相邻去重是最稳妥的。这里还有个性能细节：在 JS 里[...new Set(arr)].sort()是先哈希去重再排序，时间上通常比先排序再去重更优，因为去重后的集合变小了，排序负载更低。
5.3 全排列按字典序输出：手写 next_permutation 原理
算法题中“按字典序输出全排列”是高频硬骨头。只掌握递归回溯写全排列，输出顺序往往是“回溯序”，并非字典序；很多题目明确要求字典序，那就必须掌握“下一个排列”的套路。
原理用一句话概括：从右向左找到第一个“升序对”（前一位小于后一位），记为位置 i；再从右向左找到第一个大于 nums[i] 的数，记为位置 j；交换二者，然后把 i+1 之后的部分反转。整个序列就变成了字典序意义上的“下一个更大排列”。
function nextPermutation(nums) { let i = nums.length - 2; while (i >= 0 && nums[i] >= nums[i + 1]) i--; if (i < 0) { // 已经是最大排列，回到最小排列 nums.reverse(); return nums; } let j = nums.length - 1; while (nums[j] <= nums[i]) j--; [nums[i], nums[j]] = [nums[j], nums[i]]; let left = i + 1, right = nums.length - 1; while (left < right) { [nums[left], nums[right]] = [nums[right], nums[left]]; left++; right--; } return nums; }用这个函数，配一个升序初始数组，连续调用nextPermutation，得到的就是完整的字典序全排列。我实测过，这个套路在几个主流在线测评平台上跑 LeetCode 31 以及全排列系列，时间和空间都不输于递归回溯，而且代码可预测性更好，因为它不依赖递归深度。
需要特别说明的是，这个算法的正确性前提是输入数组初始有序。如果初始数组乱序，直接调用得到的是“当前状态的下一排列”，并不保证全排列的完整性。所以“先升序排序，再循环 next”是组合拳，别拆开用。
6. 我踩过的字典序的坑，这次帮你彻底排掉
6.1 字符串数字排序与数值排序的混淆
这是最常见的坑。代码里得到一个["item_2", "item_10", "item_1"]，直接用默认排序，结果是["item_1", "item_10", "item_2"]。视觉上 10 跑到 2 前面，特别像 bug。但字典序的规则没有错，错在没意识到“默认就是字典序”。解决方式是在比较器里把item_后面的数字拆出来转 int。也可以用一个更优雅的思路：把字符串统一补零，比如"item_2"改成"item_0002"，再排序，得到的顺序就和数值序一致。补零方案适合格式固定的场景，性能优秀。
6.2 大小写与本地化导致的“看起来不像字典序”
第二个高频坑是大小写。ASCII 码里大写字母整体排在小写字母前面，于是"Banana"会排在"apple"前面。如果产品要求“不区分大小写”，就得显式忽略 case。更麻烦的是本地化：德语、瑞典语里某些字符的排序位置和英语不一样，用数据库排序时，不同的 collation 会让相同的数据出现不同顺序。我的建议是：遇到需要面向全球用户的排序，别自己手写规则，直接用语言和数据库提供的 locale-aware 排序能力（Java 的Collator、MySQL 的utf8mb4_unicode_ci、JS 的localeCompare）。
6.3 前缀串和空格带来的排序“意外”
第三个坑是空格。有个线上 bug 是这样的：一批文件名称去重后排序，发现一个很长的文件名排在了短文件名前面，跟预期完全反了。调试半天，发现罪魁祸首是长文件名后面多了一个空格。字典序上，"abc"和"abc "比较时，短串先结束，于是"abc"排在前面，长串反而靠后。如果业务上允许字符串尾部有空格，排序前最好统一trim()一下，或者接受这种顺序并写进文档，不然排查一次成本很高。
6.4 中文字符串的排序，“字典序”到底按什么排
中文排序是一个专门的学问。直接按 UTF-8 字节排序，结果是 Unicode 码点序，和拼音、笔画、部首都没有关系。如果用户打开的页面里“张三”排在“阿明”前面，很多人觉得不对，但如果按拼音，"阿明"（a）应该排在"张三"（z）前面。解决方式很明确：需要拼音序时用数据库 collationutf8mb4_zh_0900_as_cs（MySQL 8.0），或者用Collator指定中文 locale。不能指望默认字典序替你完成本地化，它只会按码点办事。
6.5 一个用过才懂的细节：比较器务必保持传递一致性
最后分享一个相对隐蔽的坑。自定义比较器时，如果不小心让比较逻辑出现“a > b、b > c、但 c > a”这种环路，排序结果会全乱，甚至直接抛异常。Java 里可能报Comparison method violates its general contract，JS 里可能表现为排序结果不稳定。字典序本身是满足传递性的，问题往往出在你叠加了太多自定义规则。比如“先按长度排，长度相同再按字典序”这个规则，看起来合理，实际长度和字典序会打架："a"、"ab"、"b"按长度排是"a" < "b" < "ab"，但按字典序排是"a" < "ab" < "b"，两者的结果完全不同，不能叠加。要么完全用长度，要么完全用字典序，叠加前必须想清楚你是否真的想引入一个新序。
在我实际写业务的时候，每当遇到排序需求，都会把“是否覆盖了空值、大小写、空格、前缀、数字段、本地化”这六件事过一遍。大多数隐藏 bug，都藏在这些边角里。字典序看似简单，但它和其他规则一混，立刻变成雷区。以上这些，都是我从项目和线上问题里一条一条排出来的，希望你能一次避开。
