先说个最近在排查的case。某系统的任务调度模块顶层是一个按优先级出队的二叉堆每个任务下面挂了一棵依赖树代码里递归、回溯、遍历、分治几乎全用上了中间还穿插着哈希表的多轮遍历。调试到后半段我意识到一个问题很多人学算法的时候递归、回溯、遍历、分治是分开背的哈希表、子序列、二叉堆、红黑树也是分开学的但到了真实工程里它们从来都是缠在一起的。这篇就把这条线完整串一遍——这四个算法范式各自解决什么问题在四类典型数据结构里分别长什么样为什么某种结构天然就适合某个范式以及实操时最容易在哪几个地方翻车。适合两类人看一类是准备算法面试、想建立体系化理解的开发者另一类是写业务代码时总感觉数据结构和算法不太够用的工程同学。内容不算深但都是我实际写代码、排查问题时会反复用到的那部分。1. 先厘清概念四个算法范式到底在解决什么问题很多教材把这四个词当成独立的章节但在我眼里它们是不同层面的东西。递归是一种代码组织方式遍历是一种访问动作分治和回溯才是更高层的求解策略。把它们混为一谈面试和写代码都会别扭。1.1 递归与分治大问题必须能拆成同构的小问题递归的本质是函数自己调用自己。它要求一个问题可以被拆成若干个更小的、结构相同的问题直到拆到某个可以直接回答的边界然后逐层把小问题的答案拼回大问题。分治则是递归的一种典型应用模式分解、解决、合并三步走。举个例子二叉堆的层序遍历 逐层求高度看起来很直观但真要写递归版你会发现每一棵子树的高度等于左右子树高度的最大值加一。这就是分治——把整棵树的高度问题拆成左子树和右子树的高度问题。没有递归这个载体分治写起来会非常拧巴。我在工程里有一个判断标准一个问题如果天然具备树形结构、或者能画出递归树优先考虑分治如果一个结构是线性的、过程是顺序的就别硬套递归。硬套的后果就是代码难看还容易栈溢出。1.2 遍历所有访问动作的基本单位遍历是对数据结构中每个元素进行一次且仅一次访问的过程。这是动作不是策略。哈希表的遍历、二叉堆数组的遍历、红黑树的中序遍历本质上都在做同一件事按某种规则把数据取出来处理。但这个某种规则恰恰是关键的。哈希表没有内在顺序它的遍历顺序完全由桶的排列和哈希值决定二叉堆的层序遍历天然就是数组下标顺序红黑树因为有二叉搜索树性质中序、前序、后序可以给出完全不同的访问结果。理解遍历的本质是访问规则的选择很多bug的根源就清楚了——你遍历哈希表时以为它有顺序这就是最常见的误解之一。1.3 回溯解空间里的试错 撤销回溯比递归高一层。它本质上是深度优先搜索但多了一个关键动作状态撤销。走一步发现这条路不行退回来恢复现场换一条路再走。用生活的话说就是迷宫探路你手里有一团线每走到一个岔路口就做好标记继续走走到底发现是死胡同就顺着线回到上一个岔路口再试别的方向。代码里的体现就是 path.append 和 path.pop 成对出现。回溯和普通递归的差别就在这个撤销上。很多递归问题不需要撤销状态因为每个分支是独立计算的但回溯问题的各个分支共享同一个状态空间你不撤销下一个分支就会带着上一个分支的残留信息结果全错。写子序列枚举、全排列、组合问题的时候这个点踩的人特别多。2. 递归与分治在哈希表、子序列里的落地实践哈希表和子序列看起来一个偏工程、一个偏算法竞赛但它们在遍历的随机性和状态的递推性上各有讲究。我把这两个放在一组讲是因为它们的核心问题恰好互补哈希表重点在如何正确遍历和扩容重排子序列重点在如何递归建模和避免重复计算。2.1 哈希表遍历无序结构下的完整访问规则哈希表底层是数组 冲突链表开放寻址法类似。当你遍历一张哈希表实际上是先按桶的物理顺序走一遍再在冲突链上走一遍。这个顺序和插入顺序没有必然关系它取决于键的哈希值、当前桶的数量、扩容阈值等一堆工程参数。所以工程上有一条铁律遍历哈希表时永远不要假设输出有序也不要依赖顺序做逻辑判断。之前我碰过一个缓存清理模块本地测试时遍历 HashMap 总是先拿到A再拿到B清理逻辑依赖这个顺序一切正常。上生产环境后偶发B已经被清掉、但业务又回头查B的报错排查到最后才发现是测试环境数据量小、没触发扩容生产环境数据多了以后哈希表的桶结构变了遍历顺序整个反转。正确做法是需要按序访问就用有序结构比如红黑树实现的 TreeMap不需要有序但想固定访问顺序就在插入时额外维护一个顺序记录结构。纯靠遍历HashMap来保证顺序属于给自己埋雷。2.2 哈希扩容里暗藏的分治拆解思路哈希表容量不够了怎么办重新开一张更大的表把所有旧元素重新映射过去。这个过程学术上叫rehash工程上叫扩容。乍一看这是一个大规模数据搬迁问题但仔细拆解它天然契合分治思想整个搬迁任务拆解成逐桶处理每个桶独立处理互不干扰每个桶内的冲突链再拆解成逐个节点处理对每个节点重新计算索引并放入新桶最后把各桶的处理结果合并起来就是一张完整的新表。这里有没有显式的递归不一定。但分治的分解 → 解决 → 合并三步结构完全对得上。更妙的是当哈希表容量从 oldCap 翻倍到 newCap而且哈希函数做的是位运算取模时每个旧桶里的元素只会被分到两个新位置原索引或者原索引 oldCap。判断依据是哈希值新多出来的那一位是0还是1。这种按一位决定去左半区还是右半区的做法本质就是一种位级分治。理解了这一点你再看那些高性能哈希表的扩容实现就会觉得非常通透。2.3 子序列枚举递归树与回溯模板求一个数组的所有子序列是理解递归和回溯的最佳入门题。以 [1, 2] 为例每个元素只有选和不选两条路所以整个枚举过程是一棵深度为 n 的二叉树。叶节点就是所有子序列。用回溯代码写是这样的def subsets(nums): res [] def backtrack(start, path): # 记录当前路径不需要等到叶子节点 res.append(path[:]) for i in range(start, len(nums)): path.append(nums[i]) backtrack(i 1, path) path.pop() # 撤销选择回到上一叉口 backtrack(0, []) return res这里的 path.append 和 path.pop 必须成对出现而且 res.append(path[:]) 必须拷贝一份路径绝不能直接 append path。因为 path 是同一个列表对象后续的 pop 会把它改得面目全非最后 res 里存的全是同一个被清空的列表。这个坑我见过不下三次。枚举子序列的时间复杂度是 O(2^n)数据量稍微一大就扛不住。这时候剪枝就派上用场了。回溯的剪枝思路是如果当前路径已经不可能产生合法结果就直接 return不再深入。比如求所有元素和为偶数的子序列你可以在递归时实时维护当前路径和遇到不满足条件的路径提前止损这比枚举完了再统一过滤要快得多。2.4 最长递增子序列从朴素递归到动态规划子序列问题的进阶版是求最长递增子序列LIS。很多教程直接把动态规划递推公式甩出来但没讲清楚这个公式是从哪来的。我看过最顺的理解方式是从递归定义开始。设 f(i) 表示以第 i 个元素结尾的最长递增子序列长度。那么它的值等于之前所有元素中值小于 nums[i] 的那些位置对应的 f(j) 的最大值再加 1。写成递归就是from functools import lru_cache def length_of_lis(nums): n len(nums) lru_cache(None) def f(i): best 1 for j in range(i): if nums[j] nums[i]: best max(best, f(j) 1) return best return max(f(i) for i in range(n))朴素递归的问题在于 f(j) 会被重复计算很多次指数级膨胀。加上 lru_cache 做记忆化后每个 f(i) 只算一次复杂度直接降到 O(n^2)。这个 O(n^2) 再往下一步优化可以用贪心 二分降到 O(n log n)但那是另一个故事了。我想强调的是这个转化过程递归定义 → 记忆化递归 → 动态规划是一条清晰的主线。面试时如果被问到你怎么想到用动态规划的你就从递归定义讲起逻辑是完整的。工程上同理凡是能写出递推公式的地方先用递归跑通正确性再考虑用记忆化或迭代优化不要一上来就憋状态转移表。3. 遍历与分治思想在二叉堆中的工程应用二叉堆是优先队列最经典的底层实现。它的物理结构是数组逻辑结构是完全二叉树。这个数组里的树特性决定了它的一切操作都围绕两条路子顺着数组下标遍历访问顺着父子关系下滤或上滤。3.1 堆的层序遍历数组下标的父子关系堆的层序遍历串起了数组和树两个视角。某个节点的索引是 i它的左孩子是 2i1右孩子是 2i2父节点是 (i-1)/2。所以堆的层序遍历根本不用建树直接按数组顺序访问就是层序结果。这个性质让堆在很多场景下比树形结构更快——没有指针、没有节点对象只是一块连续内存。我在工程里用这个特性做过一件很土但很有效的事一个异步任务池需要按优先级取出任务同时按创建时间统计配额。如果为这两个维度分别建堆内存和代码复杂度都不划算。后来发现任务的优先级本身就是一个小范围的离散值我直接开了几个数组当桶每个桶内维护一个堆层序遍历时顺便统计配额。遍历数组的开销比遍历指针树小几个数量级这个方案实测下来非常稳定。但要注意堆的层序遍历只保证父节点和子节点的相对顺序不保证兄弟节点之间的顺序。你要输出严格有序的结果堆本身不提供这个能力得借助堆排序或者换用其他结构。3.2 下滤与上滤递归视角下的两种堆化方式建堆有两种思路自顶向下逐个插入每次上滤或者自底向上逐个调整每次下滤。很多教材会告诉你自底向上建堆更快但没说透为什么。上滤建堆的思路是每来一个新元素就放到末尾然后和父节点比较破坏了堆性质就往上交换。每个新元素的调整路径长度取决于它的深度整体复杂度是 O(n log n)。下滤建堆的思路是从最后一个非叶子节点开始逐个把自己子树调整成合法的堆。注意这里是递归视角调整节点 i 时先保证它的左右子树已经是合法堆再比较 i 和左右孩子谁大把最大的换上来然后继续顺着交换方向向下调整。这个过程满足分治的完整性——每个子树都是独立的子堆问题。它的总复杂度是 O(n)因为大多数节点所在层级比较低调整代价小。递归版的下滤代码长这样def sift_down_recursive(heap, n, i): largest i left 2 * i 1 right 2 * i 2 if left n and heap[left] heap[largest]: largest left if right n and heap[right] heap[largest]: largest right if largest ! i: heap[i], heap[largest] heap[largest], heap[i] sift_down_recursive(heap, n, largest)递归版本逻辑很好读但工程上我更推荐迭代版本原因有两个堆的深度在 log n 量级递归栈开销本身可控但高频调用下函数调用成本累积起来仍然可观更重要的是迭代版本中间不产生隐含返回栈调试起来心智负担小得多。3.3 堆排序与优先队列分治思想的高级形态堆排序的完整流程是先用下滤建堆然后把堆顶和最后一个元素交换堆大小减一再次对新的根执行下滤。重复这个过程数组就排好序了。从分治角度看堆排序和归并排序一样都是把大问题拆成子问题再合并的思路只不过拆的方式不同。归并把数组拆成左右两半各自排序再合并堆排序则是不断把当前范围内最大的元素提取到正确位置本质上是对一个最大堆反复执行弹出堆顶。堆排序不需要额外空间不稳定但在优先级调度这种场景下它比全量排序实用得多。我做的那个任务调度模块核心就是维护一个最大堆每次取出优先级最高的任务然后对堆做一次下滤。任务完成之后偶尔会有新任务插入就执行一次上滤。这种每次只取一个元素 每次只改一部分的需求优先队列比全排序优雅得多。如果你需要频繁获取最大或最小值且插入删除操作也频繁优先队列就是默认答案。4. 红黑树里的递归旋转、回溯修正与有序遍历红黑树是工程里最实用的平衡二叉搜索树实现很多语言的有序映射都是在它之上构建的。它比 AVL 树宽松但最坏情况下高度仍能保持 O(log n)。要读懂红黑树绕不开三个关键词递归旋转、回溯修正、有序遍历。4.1 工程里为什么最终选了红黑树先回答一个常见疑问AVL树比红黑树更平衡为什么工程上反而几乎都用红黑树答案是严格平衡带来的查找优势在插入删除频繁的场景里吃不消。AVL树追求左右子树高度差不超过1插入/删除后经常触发旋转旋转本身成本高。红黑树只要求从根到叶子的黑色节点数量相同允许红节点存在且相邻红节点不允许所以它要求的平衡度宽松很多插入删除时触发旋转的概率比 AVL 低。对于读多写少的纯查询场景AVL可能略快对于通用场景红黑树的综合吞吐量更好。Java的TreeMap、C的std::map底层都是红黑树。这个选择逻辑也体现了工程思维性能不是单一指标的极致而是插入、删除、查找、范围遍历等多个操作的综合权衡。4.2 插入修正一趟自底向上的回溯红黑树的插入分两步。第一步按普通二叉搜索树规则找到空位插入新节点。第二步把新节点染成红色然后从新节点开始沿着父链向上检查并修正红黑树性质。为什么新节点必须染成红色因为红色节点不改变任何路径的黑色节点数量也就是说不会破坏性质5任一节点到叶子的每条路径黑高相同。只要不破坏黑高问题范围就小多了。插入一个红节点最可能破坏的是性质4红色节点的子节点必须是黑色。也就是说如果父节点也是红色就冲突了。修正过程就是一趟回溯。当前节点是红色父节点也是红色祖父节点必然是黑色否则原来就冲突。这时分三种情况叔节点是红色把父节点和叔节点染黑祖父节点染红然后把当前节点上移到祖父继续循环。这一操作把红冲突往上推了一层。叔节点是黑色且当前节点是父节点的右孩子对父节点左旋把折线变成直线继续进入下一种情况。叔节点是黑色且当前节点是父节点的左孩子对祖父右旋同时交换父节点和祖父的颜色。最后强制根节点染黑。这个修正过程的外层 while 条件就是当前节点不是根 父节点是红色。它从被插入的叶子出发一层一层向上回溯直到冲突消解或到达根。这不就是回溯嘛——向上回溯、修状态、再往上、再修状态。和经典的N皇后一样都是在一条路径上反复检查和修正。为了方便理解我贴一个标准框架CLRS风格简化版def insert_fix(tree, node): while node ! tree.root and node.parent.color RED: parent node.parent grand parent.parent if parent is grand.left: uncle grand.right if uncle and uncle.color RED: # case 1 parent.color BLACK uncle.color BLACK grand.color RED node grand # 回溯到祖父 else: if node is parent.right: # case 2 node parent left_rotate(tree, node) # case 3 parent.color BLACK grand.color RED right_rotate(tree, grand) else: # 镜像对称处理逻辑相同只是方向相反 pass tree.root.color BLACK这里有个容易忽略的工程细节叔节点可能为空。在红黑树里空节点视作黑色叶子节点所以判断条件里uncle and uncle.color RED中的uncle如果为None就等于情况2/3而不是情况1。很多初学手写红黑树的人在这里翻车把空叔节点当红色处理颜色关系直接错乱。4.3 删除修正里的双黑问题插入修正已经很绕了但删除修正才是完整红黑树实现里真正让人头疼的部分。删除一个节点后如果被删节点是黑色那某些路径的黑高就少了1破坏了黑高性质。为了修复需要引入双黑概念把那个缺失的黑色想象成叠加在某个节点上让这个节点变成双重黑色然后通过一系列旋转和变色把多余的黑色往上推直到某个祖先节点或者根。修正的起点是经过交换后实际被删除节点的位置也一样需要沿着父链向上回溯。这个回溯过程比插入更复杂因为除了颜色翻转还要考虑兄弟节点及其子树的各种颜色组合。红黑树的删除修正为什么难因为它面对的状态分支更多而且每种分支对应不同的旋转策略。如果你只是需要工程可用别硬记所有情况直接记住结论删除修正常见的五种情况核心目标是把双黑问题不断上移或最终消除。我的实操建议是手写红黑树删除时先在纸上画出对应的六种状态树每次编码时对照自然状态图而不是背伪代码。这样出错率低得多。4.4 中序遍历红黑树如何给出有序结果红黑树本质还是二叉搜索树所以它的中序遍历左-根-右天然产生有序序列。这正好弥补了哈希表无序遍历的短板。工程里如果你既要快速查找又要范围遍历红黑树是标配。中序遍历的递归代码非常干净def inorder(root, result): if root is None: return inorder(root.left, result) result.append(root.key) inorder(root.right, result)虽然红黑树有旋转、染色等复杂操作但它最终给用户的接口依然是一个有序集合。这个实现复杂度高、对外接口简单的特点正是工程结构的典型范式——复杂度收敛在内部实现里外部只暴露稳定语义。5. 实操环节核心代码实现与一次对比前面讲了原理这一节我把四个算法范式在四类结构中的关键代码串一遍直接用能跑的片段说话方便你直接抄到自己的工程里改造。5.1 回溯枚举子序列的通用模板子序列枚举是回溯最标准的应用。如果你理解了选/不选模型所有组合类问题包括全排列、组合总和、分割回文串都是从同一个模板变出来的。def subsets(nums): res [] path [] def backtrack(start): res.append(path[:]) # 记录当前状态 for i in range(start, len(nums)): path.append(nums[i]) # 选择 backtrack(i 1) # 进入下一层 path.pop() # 撤销选择回溯 backtrack(0) return res关键在于path[:]拷贝而不是直接引用path.pop()必须紧跟在递归返回之后保证每次循环开始前状态是干净的。这个模板的时间复杂度 O(2^n) 无法避免但空间复杂度可以控制路径复用同一个列表不产生大量中间数组。5.2 二叉堆递归下滤与建堆建堆时用下滤方法写一个工具函数def build_max_heap(arr): n len(arr) # 从最后一个非叶子节点开始自底向上下滤 for i in range(n // 2 - 1, -1, -1): sift_down_iterative(arr, n, i) return arr def sift_down_iterative(heap, n, i): while True: largest i left 2 * i 1 right 2 * i 2 if left n and heap[left] heap[largest]: largest left if right n and heap[right] heap[largest]: largest right if largest i: break heap[i], heap[largest] heap[largest], heap[i] i largestn // 2 - 1是最后一个非叶子节点的下标。从这里向下往前逐个下滤就能保证每个子树先变成合法堆这正是分治思想的落地。5.3 红黑树插入修正的回溯框架前面给的是伪代码这里给一个更贴近可运行实现的结构。你可以在已有的红黑树类里直接替换修正函数def insert_fixup(tree, node): while node is not tree.root and node.parent.color RED: parent node.parent grand parent.parent if parent is grand.left: uncle grand.right if uncle is not None and uncle.color RED: # 情况1变色并把问题向上传递 parent.color BLACK uncle.color BLACK grand.color RED node grand else: if node is parent.right: # 情况2把折线旋转成直线 node parent tree.left_rotate(node) # 情况3直线状态下旋转祖父 parent.color BLACK grand.color RED tree.right_rotate(grand) else: uncle grand.left if uncle is not None and uncle.color RED: parent.color BLACK uncle.color BLACK grand.color RED node grand else: if node is parent.left: node parent tree.right_rotate(node) parent.color BLACK grand.color RED tree.left_rotate(grand) tree.root.color BLACK运行这个函数时我强烈建议在每次旋转前后打印树结构结合小数据比如 [1, 5, 3, 4, 2] 一组用例。看状态变化比单纯背代码有效得多。5.4 简化版哈希表扩容模拟下面这段代码不直接对应某个具体语言的实现而是模拟哈希表容量翻倍时的 rehash 过程。注意看它是如何把整个搬迁任务拆成逐桶处理 逐节点重映射的。def resize_buckets(old_buckets, new_capacity): new_buckets [[] for _ in range(new_capacity)] for bucket in old_buckets: # 外层逐桶分解 for key, value in bucket: # 内层逐个节点解决 new_index hash(key) % new_capacity new_buckets[new_index].append((key, value)) return new_buckets如果容量恰好是原来的两倍而且 hash 函数是位运算式取模那你还能进一步优化不需要对每个节点重新做一次耗时的 hash 计算只要看新增位是0还是1直接决定放原位置还是原位置 old_capacity。这就是工程里常见的 rehash 优化也让我更确信分治思想在哈希表内部是真实存在的。5.5 一次粗略的性能对比结果我在普通开发机上对不同方案做过一组量级测试结论仅供参考但趋势非常稳定100万个随机整数建最大堆自底向上下滤比逐个上滤插入快接近一个数量级。原因就是 O(n) 对比 O(n log n)在百万级别数据上差距立刻拉开。相同数据量下遍历连续数组形式的堆比遍历指针树形式的结构快约 2-3 倍。缓存友好、无指针跳转是关键优势。红黑树插入修正的平均旋转次数远低于实际违反红黑树性质的修正次数因为只需要少量旋转和变色就能恢复平衡。越是大量插入这个优势越明显。这些结果没有输出具体毫秒数是因为不同语言、内存模型差异太大。但下滤建堆优于上滤建堆数组结构访问优于指针结构属于稳定的工程结论可以放心参考。6. 常见问题速查与排坑实录这些年写代码、做面试、带新人在这四个算法范式相关的问题上反复遇到一些共性坑。整理成速查表每个坑都是真实项目里撞出来的。6.1 递归深度压垮调用栈递归看起来优雅但每层递归都要占用栈帧深度超过几万层栈就顶不住。典型场景树形菜单的递归遍历、子序列枚举的深度过深、红黑树这种 log n 深度的结构其实还好但线性链表的递归遍历就容易出事。解决办法有三个改尾递归很多语言能优化成迭代、显式用栈模拟、或者换个非递归思路。工程上我现在更推荐显式栈因为你不需要依赖语言对尾递归的支持。遇到递归太深导致 StackOverflow的报错先别急着调栈大小先看能不能改成迭代。6.2 哈希表遍历顺序忽变这是工程里最容易踩的隐性坑。哈希表遍历顺序受哈希种子、容量、负载因子、键的哈希值共同影响进程重启都可能导致顺序变化。如果你的逻辑依赖遍历顺序短期内可能没问题但某次扩容或换了一台机器就突然出bug。我现在的习惯是任何需要稳定顺序的地方一律避免遍历哈希表。要么用有序结构要么在插入时额外维护顺序列表。千万不要写反正现在顺序是固定的就这么干的赌注代码。6.3 堆排序悄悄改变同值顺序堆排序是不稳定的排序算法。为什么因为堆调整过程中相同键值的元素可能跨区域交换顺序就乱了。如果你按任务优先级排序两个同优先级任务原来先后进入队列堆排序可能把它们颠倒。排查这类 bug 的典型路径是任务调度偶发乱序本地单线程复现不出来并发压测下频率上升最后定位到排序算法不稳定。一个已经不常见的解决方式是用稳定排序替代但更彻底的做法是让比较器中加入一个不会相同的次要键比如插入序号。这样堆排序的不稳定性就和你无关了。6.4 手写红黑树的老三样坑红黑树实现代码不长但每次手写都有人栽在这三个地方第一是叔节点为空的情况。前面说过空节点是黑色不能把空节点当红色处理否则会走进错误的分支。第二是祖父节点为空的情况。当 current node 上移到根位置时循环应该终止最后一律把根染黑。第三是旋转之后 node 的指向没有及时更新。旋转可能改变父子关系如果 node 还指向旧节点下一次循环判断就会出错。我的排查技巧是插入后逐层检查从当前节点向上打印每一层的颜色和祖父关系再配合中序输出验证二叉搜索树顺序。两步都对了基本能排除绝大多数问题。6.5 常见问题速查表问题现象根因解决办法递归调用栈溢出递归层数过大栈帧堆积改迭代、显式栈、尾递归优化遍历哈希表结果飘忽不定依赖了哈希表遍历顺序改用有序结构或单独维护顺序同优先级任务顺序颠倒堆排序不稳定比较器加入稳定次序字段红黑树插入后根变红遗漏最后的强制根节点染色修正循环结束时置根为黑子序列结果全是空列表res.append(path)没有拷贝改用path[:]拷贝回溯结果多出奇怪分支忘记调用path.pop()撤销保证选择与撤销成对出现这个表格的每一行背后都对应一次真实的排查过程。我的建议是不要只收藏遇到类似问题时对比排查。算法思想能帮你设计出方案但排查技巧才是工程上真正拉开效率差距的地方。最后分享一个小习惯。我现在拿到任何算法或数据结构问题都会先问三个问题这个结构适合用哪种遍历方式这个问题能不能拆解成递归子问题如果要在所有候选解里找合法解是不是需要回溯剪枝想清楚这三件事再动手写出来的代码结构会清晰得多。四个范式和四类结构不是考试大纲上的零散考点而是同一套工程思维在不同形状的数据上的投影。