1. 先坦白这个项目的由来：一段递归与生活规则碰撞的脑洞
如果你也是个程序员，大概率经历过这种时刻：某个深夜刷到一条帖子，标题写着“程序员如何用代码解决XX生活难题”，你一边吐槽这玩意儿毫无实际意义，一边忍不住打开编辑器开始敲。我这个项目就是这么来的。标题叫“代码写离婚协议：用递归函数分割孩子”，听起来挺惊悚，但本质上是一次抽象建模练习：把抚养权分割当做一个加权资源分配问题，用递归函数去求解最优分割方案，再用软件测试的方法论去验证这个函数的正确性与鲁棒性。
先说明白，这个项目从头到尾只是一个思维实验。代码里出现的“成员”“权重”“分割方案”都是抽象概念，用来模拟一种“如何把一组对象尽量均衡地分成两组”的算法问题，绝对不能落到真实家庭场景里。真实世界的抚养权分割涉及法律、情感、孩子意愿、生活连续性等无数复杂因素，不是任何算法能替代的。我之所以用这个场景来做项目，是因为它足够有画面感，能让递归“子问题分解”的思想非常直观地浮现出来。比起写一个“数组二分”，给成员加上名字和权重之后，递归树就变成了活生生的“谁跟谁”的故事。
这个项目适合谁看？我觉得至少有三类人能从里面拿到东西：正在学递归、想看看递归除了遍历目录和算阶乘之外还能怎么用的新手；做后端或算法开发、想系统整理软件测试用例设计思路的工程师；以及对“鲁棒性”这个词有感知、但还没系统思考过“防御性编程到底防什么”的人。我在项目里真实地写了代码、写了测试、也故意埋过雷，下面就把整个过程摊开来讲。
2. 需求建模：把家庭抚养权分割抽象成递归问题
2.1 问题的数学本质：加权子集划分
先别急着写代码，建模这一步是最容易被跳过的，但恰恰决定了后面所有工作的质量。我最初的想法很简单：有一组成员，每个成员带一个权重，权重值代表“这个成员对某一方的相对重要性”或“双方争夺该成员时的心理预期强度”。目标是把所有成员分到左右两个组里，让两个组的权重总和差值的绝对值尽量小。这在算法上有一个标准名字：加权子集划分问题（weighted partition problem），是 NP 难问题的一种。
很多人一听到 NP 难就觉得“这题没救了”，但其实分情况。成员数量少的时候，穷举所有 2 的 n 次方种分配是完全可行的；成员数量多的时候，就需要退而求其次，用贪心、启发式或近似算法。这个项目故意卡在“小规模枚举最优”的范围内，目的是把递归与剪枝讲透，同时用鲁棒性设计兜住“规模变大”的场景。所以，这个函数不是要解决所有规模的划分问题，而是要在一个合理边界内给出确定、可验证、可测试的结果。
用一个生活类比来帮助理解：想象你有一堆零食要分给两个朋友，每样零食在两人心中的分量不一样（有人喜欢薯片，有人喜欢巧克力）。你希望这堆零食拆成两份之后，两个人拿到手的“总喜爱度”差不多。递归的暴力做法就是：第一包零食给甲还是给乙？每一轮都做一次决定，最后一轮结束后看双方总分差多少。这就是一棵天然的分支树。
2.2 递归三要素在“分割成员”上的映射
递归三要素是终止条件、递归调用、状态收敛。这套东西放在阶层、斐波那契数列上很好理解，但要落到“成员分割”上，需要重新映射一下。
终止条件，在这个项目里就是“所有成员都已经做出归属决策”，也就是索引走到成员列表末尾。此时不再产生新分支，直接比较左右两组的权重差，如果比当前记录的最优值更小，就更新最优方案。递归调用，则是“当前成员尝试放入左侧”和“当前成员尝试放入右侧”两条分支，分别递归处理下一个成员。状态收敛，体现在每次递归调用时索引加一，剩余待处理成员逐个减少，最终必然到达终止条件。
这三个要素听起来简单，但实际实现时有一个容易被忽略的点：递归函数不仅要返回“最小差值”，还要能回溯输出“具体是哪几个成员在左边、哪几个在右边”。这就是为什么我设计了一个 SplitPlan 数据结构，用来承载 left、right 和 diff 三个字段。差值是目标函数，left 和 right 是方案本身，两者必须一起更新、一起回传，否则你最后算出了最优差值，却不知道对应方案是什么，那这个函数实用性就大打折扣。
2.3 为什么不用贪心、动态规划或整数规划
写代码之前我认真想过其他方案。贪心算法最简单：按权重从大到小排序，每次把当前成员放到权重总和更小的那一侧。这个方案跑得快，但它不保证全局最优，而且对顺序敏感，极度依赖输入数据的排列方式。动态规划可以做到精确求解，但当权重是浮点数或值域很大时，DP 表的维度根本建立不起来，状态会爆炸。整数规划需要引入第三方求解器，比如 PuLP 或 OR-Tools，虽然专业，但把简单问题复杂化了，而且不好演示递归思想。
所以最终选择了“递归 + 回溯 + 剪枝”。这个方案有三个好处：第一，递归结构天然匹配问题的分支决策特性，代码直观；第二，借助剪枝可以显著缩小搜索空间，在成员规模不太大的时候跑得动；第三，它给软件测试留出了大量发挥空间——我完全可以故意设计一个错误剪枝，让测试用例把它揪出来，这比任何理论讲解都有说服力。
3. 核心实现：递归函数与剪枝策略的落地
3.1 数据结构与接口设计
代码用什么语言？我选了 Python，不是因为它性能最强，而是因为它表达力高、写测试方便，pytest 生态成熟，适合做一个“算法原型 + 测试驱动”的项目。数据结构的核心是 Member 和 SplitPlan 两个类。
from dataclasses import dataclass, field from typing import List, Optional @dataclass class Member: name: str weight: float @dataclass class SplitPlan: left: List[str] = field(default_factory=list) right: List[str] = field(default_factory=list) diff: float = float('inf')Member 有两个属性：name 和 weight。name 在这个项目里承担的是“可读性”职责，方便在输出方案时直接看到“小A跟谁、小B跟谁”。如果你把 name 改成 id，这个类就变成了纯粹的工业级需求。我在设计时特意把 name 保留为字符串，是因为项目演示阶段，可读性比性能重要得多。SplitPlan 则用来存放一次分割的结果：左组成员名列表、右组成员名列表、两组权重差绝对值。diff 初始化为无穷大，是为了让任何真实差值都能更新它。
3.2 递归核心逻辑与安全剪枝
核心递归函数是一个内部函数，我把它封装在对外入口split_members里，外部只调用入口，不直接触碰递归细节。这样设计的好处是接口稳定，后续改动内部实现不会破坏调用方。核心代码如下：
MAX_BRUTE_FORCE_N = 18 def split_members(members: List[Member]) -> SplitPlan: if not members: return SplitPlan() for m in members: _validate_member(m) if len(members) > MAX_BRUTE_FORCE_N: raise ValueError(f"成员数量超过精确计算上限 {MAX_BRUTE_FORCE_N}，请使用启发式方案") best = SplitPlan() total_weight = sum(m.weight for m in members) remaining = [total_weight] # 用列表存剩余权重，方便递归内修改 def dfs(idx: int, left: List[str], right: List[str], left_sum: float, right_sum: float) -> None: if idx == len(members): diff = abs(left_sum - right_sum) if diff < best.diff: best.left = left[:] best.right = right[:] best.diff = diff return current_diff = abs(left_sum - right_sum) # 安全剪枝：即便把剩余所有权重都补到较小的一侧，也追不上当前最优解 if current_diff - remaining[0] >= best.diff: return member = members[idx] remaining[0] -= member.weight left.append(member.name) dfs(idx + 1, left, right, left_sum + member.weight, right_sum) left.pop() right.append(member.name) dfs(idx + 1, left, right, left_sum, right_sum + member.weight) right.pop() remaining[0] += member.weight dfs(0, [], [], 0.0, 0.0) return best这段代码里有几个细节值得展开。第一个是剪枝条件current_diff - remaining[0] >= best.diff。我特别强调“安全剪枝”，因为剪枝的本质是用“数学上可以证明不可能更优”的断言去砍掉整个分支，而不是拍脑袋觉得“差不多了可以停”。这个条件是安全的：即使剩余所有权重全部加到当前权重较小的一侧，差值最多也只能改善remaining[0]，如果改善之后的差值仍然大于等于已知最优值，那这个分支无论如何都不会产生更好的解，可以直接砍掉。
第二个细节是remaining用一个长度为 1 的列表来存，而不是用 Python 的nonlocal变量。这算是我的一个编码习惯：在递归内部修改外部变量时，列表可以避免nonlocal声明，写起来更顺手。当然用nonlocal也行，这只是风格差异。
第三个细节是副本拷贝left[:]和right[:]。递归过程中 left 和 right 是不断变动的，如果直接把引用赋给 best 对象，后续回溯时执行pop会把 best 里的内容也弹掉。这个 bug 我一开始就踩过，后面在测试部分会专门讲。
3.3 统一入口与参数校验
_validate_member是参数校验函数，确保每个 Member 的 name 是字符串、weight 是非负有限浮点数。这个在前置防御部分非常关键，我先在代码里留一个位置，后面鲁棒性设计章节会详细说明为什么这么写。现阶段的版本只做了最基本的空列表处理，就给测试阶段留了很多“攻击面”。
def _validate_member(member: Member) -> None: if not isinstance(member, Member): raise TypeError("member 必须是 Member 类型") if not isinstance(member.name, str): raise TypeError("member.name 必须是字符串") if not isinstance(member.weight, (int, float)): raise TypeError("member.weight 必须是数值") if isinstance(member.weight, bool): raise TypeError("member.weight 不能是布尔值") if member.weight < 0: raise ValueError("member.weight 不能为负数") if member.weight != member.weight: # NaN 检测 raise ValueError("member.weight 不能为 NaN") if member.weight in (float('inf'), float('-inf')): raise ValueError("member.weight 不能为无穷大")写到这里，我的项目已经具备了可运行的核心逻辑。但说实话，这段代码从“看起来能跑”到“真的可靠”之间，还隔着一整个软件测试的距离。
4. 软件测试视角：怎么证明这个递归函数没有背叛规则
4.1 先想清楚要测什么：正确性约束
写测试用例之前，我列了一份“这个函数必须满足的规则清单”，每一条都对应一个或多个测试。这份清单是整个测试工作的核心资产，远比具体的测试代码重要。
第一，完整性约束：每个成员必须恰好出现在一个分组里，不能漏掉，不能重复出现。第二，合法性约束：左组和右组的并集必须等于全部输入成员，交集必须为空。第三，最优性约束：返回的差值必须是真实最小差值，这是这个项目的灵魂指标。第四，边界约束：空输入、单成员输入、两个相等权重成员这类极端情况要能正确处理。第五，异常约束：非法输入必须抛出明确异常，而不是静默返回错误结果或直接崩溃。
这些约束听起来平淡无奇，但每一种都能设计出对应的具体测试用例。有意思的是，最优性约束最难验证——你无法直接断言“这就是全局最优”，因为你没有一个独立的参照实现。我的做法是拿递归结果跟一个更慢但逻辑更简单的暴力枚举实现对比，用随机数据跑多组，两边结果一致才放心。这种“用另一个实现来互相验证”的思路，在测试领域叫对拍（metamorphic testing 的简化版），非常实用。
4.2 测试用例设计：等价类与边界值的组合
软件测试面试题里常考等价类划分和边界值分析，这里正好实践一遍。我把输入域分成几个等价类：正常普通输入（2 到 6 个成员，权重各异）、全相等权重输入、包含浮点数权重的输入、包含零权重成员的输入、空输入、单成员输入、超大规模输入、非法输入（负数权重、NaN、非数值权重、None 成员）。每个等价类里再挑典型值，组成完整测试矩阵。
边界值是重点。权重为 0 的成员是个特殊的边界，因为从数学上看它不影响差值，但它会影响方案的具体名单——把零权重成员放左还是放右，差值都是最优，这也意味着“最优方案不唯一”。函数应该稳定地返回其中一个方案，而且不应该因为零权重成员的加入而崩掉。另一个边界是浮点精度，比如 0.1、0.2、0.3 这类小数，计算差值时可能产生不可预期的小尾巴，测试断言需要使用pytest.approx或math.isclose，不能直接写assert diff == 0.0。
4.3 自动化测试脚本：pytest 实测
我的项目使用 pytest 框架组织测试，测试文件结构如下：
import pytest from splitter import split_members, Member, SplitPlan def test_empty_members(): plan = split_members([]) assert plan.diff == 0.0 assert plan.left == [] assert plan.right == [] def test_single_member(): plan = split_members([Member("小A", 5.0)]) assert plan.diff == 5.0 assert len(plan.left) + len(plan.right) == 1 def test_two_equal_members(): plan = split_members([Member("小A", 3.0), Member("小B", 3.0)]) assert plan.diff == 0.0 def test_classic_three_members(): plan = split_members([ Member("小A", 1.0), Member("小B", 2.0), Member("小C", 4.0) ]) assert plan.diff == pytest.approx(1.0) def test_completeness_and_uniqueness(): members = [ Member("小A", 1.0), Member("小B", 2.0), Member("小C", 4.0), Member("小D", 1.0) ] plan = split_members(members) all_names = plan.left + plan.right assert sorted(all_names) == sorted(["小A", "小B", "小C", "小D"]) assert len(all_names) == len(set(all_names)) # 无重复 def test_invalid_negative_weight(): with pytest.raises(ValueError): split_members([Member("小A", -1.0)]) def test_invalid_nan_weight(): with pytest.raises(ValueError): split_members([Member("小A", float('nan'))])我特别想展开讲test_classic_three_members。输入权重是 1、2、4，总和是 7，奇数，不可能完全平分。最优方案是 [1, 2] 对 [4]，差值正好是 1。这个用例简单但强大，因为它能立刻暴露一个常见的错误写法：直接贪心地每次把成员塞给当前和更小的一侧。贪心会把 4 先给左侧，然后 2 给右侧，1 给右侧，得到左侧 4、右侧 3、差值 1，看着对了；但换一组数据就露馅。所以这个三成员用例是“基准回归测试”，任何后续修改都不能让它失败。
4.4 非功能测试：顺序无关性、性能与稳定性
除了功能正确，我还加了非功能测试。顺序无关性测试是这样：把成员列表随机打乱几次，分别调用split_members，检查返回的差值是否一致。理论上，因为递归会穷举所有组合，结果与顺序无关。但如果代码里混入了“第一个找到的即可”这类提前退出逻辑，顺序就会影响结果。我在这个项目里就遇到了这种情况——后续会在问题排查章节详细讲。
性能测试我用了比较土的办法：直接测不同规模成员数量下的运行时间。n=10 时秒回，n=15 时大概 100 毫秒以内，n=18 时可能到 1 秒多，n=20 会明显卡顿。所以我定了MAX_BRUTE_FORCE_N = 18作为精确计算的上限。这个阈值不是拍脑袋定的，而是基于我的开发机实测：超过 18 个成员，全量递归的时间抖动太大，不适合做在线调用，必须走兜底策略。
def test_performance_within_budget(): import time members = [Member(f"M{i}", i % 5 + 1) for i in range(15)] start = time.time() split_members(members) elapsed = time.time() - start assert elapsed < 1.0这个测试看起来简单，但它是在给整个算法设定性能契约。如果未来某天有人改动了剪枝逻辑，导致性能退化，这个测试会在提交阶段就亮红灯。
5. 鲁棒性设计：把函数从“能跑”练到“难打垮”
5.1 输入防御：把脏数据挡在门外
做算法题的时候，输入通常被假定是合法且友好的，但真实软件世界的输入永远是不可信的。调用方可能传入 None、传入字符串列表、传入带 NaN 权重的 Member，甚至传入一个把 weight 字段拼错的对象。这些情况如果不在入口处拦截，伤害会在递归的深处爆发，到那时错误信息就变得极其难懂。
所以我在入口split_members的第一步就做了参数校验。校验逻辑全在_validate_member里，包括类型检查、值域检查和 NaN 检查。特别要提的是布尔值检查，因为在 Python 里bool是int的子类，isinstance(True, int)返回 True，如果不单独排除，权重为 True 的成员会被当成权重 1 处理，非常隐蔽。这种 bug 靠肉眼极难发现，但一个简单的单元测试就能钉死。
NaN 的检查用的是member.weight != member.weight这个技巧，因为 NaN 不等于任何数，包括它自己。如果想更明确，也可以用math.isnan(member.weight)。无穷大的检查直接用math.isinf。这些防御在普通教学代码里经常被省略，但在生产环境，缺一个就可能在某个凌晨被线上报警炸醒。
5.2 递归深度与运算量保护
Python 的默认递归深度限制是 1000。这个项目里我设了MAX_BRUTE_FORCE_N = 18，纯递归层数最多 18 层，远低于限制。但如果你把这个递归函数复用到其他场景，没有深度保护，一旦 n 超过 1000，就会直接抛出RecursionError，进程可能因此崩溃。所以我做了一个更严谨的决策：不依赖 Python 的默认限制，而是在入口显式检查成员数量。超过MAX_BRUTE_FORCE_N时，不是直接报错退出，而是抛一个带有明确提示的异常，告诉调用方“精确搜索不可用，请切换方案”。
这里有一个经验：限制数值阈值最好用常量定义，集中管理，而不是散落在代码里。我用了MAX_BRUTE_FORCE_N = 18这个命名，含义一目了然。后续如果要调整性能预算，只要改一处。
运算量保护是另一个层面。纯粹 2 的 18 次方是 26 万条分支，加上剪枝后实际探索的分支远小于这个数，但最坏情况下仍然可能在 1 秒左右波动。我把性能测试也纳入了测试套件，这样每次修改后跑一遍全套测试，就能知道当前性能预算有没有被突破。
5.3 兜底策略与可复现性
当输入规模超过精确计算上限，函数直接抛异常是安全的选择，但不是最友好的选择。从用户视角看，他手里有 25 个成员要分，你让他“请换方案”，他只能干瞪眼。所以在设计鲁棒性时，我预留了一个兜底策略：使用“按权重从大到小贪心”的启发式方案，虽然不保证最优，但能在极短时间内给出一个相对合理的结果。
贪心的实现很简单：按权重降序排序，逐个放到当前总和更小的一侧。但这个策略有一个隐藏缺陷：对输入顺序敏感。如果两个成员权重相同，排序后谁在前谁在后会影响结果，进而影响最终差值。为了让结果可复现，我在兜底前先对成员列表做一次稳定排序，排序依据是(-weight, name)，确保任何输入顺序下，兜底方案都完全一致。这就是“可复现性”的重要性——同一组输入，无论调用多少次、从哪个线程调用，都必须得到同样的输出。
5.4 错误信息与异常体系
异常处理最怕两件事：静默吞错和抛出不带上下文的裸异常。静默吞错表现为 catch 到异常后打印一行日志然后继续执行，导致后续数据都是脏的；裸异常表现为代码里写raise Exception("error")，调用方完全不知道是参数问题、规模问题还是内部逻辑问题。
我在项目里定义了专用的异常类型：
class SplitError(Exception): """分割模块统一异常基类""" pass class SplitInputError(SplitError): """输入数据非法""" pass class SplitScaleError(SplitError): """输入规模超出精确计算能力""" pass这样一来，调用方可以用except SplitError捕获所有该模块的异常，再根据子类判断是输入问题还是规模问题。错误信息里我会包含成员数量、触发校验的成员名等上下文信息，方便日志排查。好的异常设计不是越复杂越好，而是让调用方在 catch 到异常的那一刻，就知道下一步该做什么。
6. 问题排查实录：测试替我揪出的几个隐藏坑
6.1 剪枝条件“优化”导致非最优解
这是我项目里踩过最典型的一个坑。最初版本的剪枝条件写得非常激进：
if current_diff >= best.diff: return我当时的想法是：当前差值已经大于等于最优值了，后面再怎么分也没希望，直接剪掉。这个逻辑看起来天衣无缝，但有一个致命问题：当前差值大，不代表最终差值大。因为后面剩余成员还没分配，可能全部堆到较小的一侧，把差值拉回来。比如当前 left_sum=10、right_sum=1，差值 9，已知最优是 8，剩余成员权重总和是 5。如果把剩余全部加到右侧，最终差值变成 4，完全能刷新最优。我的激进剪枝直接把这条分支砍了，导致函数在某些输入下返回的不是真正最优方案。
这个 bug 是怎么被发现的？不是靠 code review，而是靠一条随机化对拍测试：生成随机成员列表，分别用无剪枝的暴力版和带剪枝版本跑，对比差值是否一致。第一次跑就出现了不一致，定位到剪枝条件后，我把它改成了current_diff - remaining[0] >= best.diff这个安全版本。这个故事很好地说明了测试的价值——不是检测“代码能不能跑”，而是检测“代码的结论是否违背了它自己承诺的规则”。
6.2 递归深度炸掉的那一刻
有一次我把MAX_BRUTE_FORCE_N临时调大到 1200，想看看性能曲线，结果函数直接抛了RecursionError。这才意识到我的递归深度保护实际上依赖于成员数量上限，而不是显式的深度检查。如果哪天有同事把上限改大，或者把split_members的逻辑复用到别的场景，这个隐患就会爆发。
解决方案是双保险：一方面保留MAX_BRUTE_FORCE_N这个规模约束，另一方面在递归函数内部加一个显式的深度计数，超过预定MAX_DEPTH = 900就直接抛异常。深度保护不能依赖 Python 解释器的默认限制，而是要在自己代码里显式声明。这次踩坑让我养成了一个习惯：任何递归函数，第一行就要想清楚深度上限是多少，而不是赌“现在数据量小，不会出事”。
6.3 浮点比较翻车与成员顺序引发的稳定危机
浮点数问题很有欺骗性。我写了一个断言assert plan.diff == 0.0，在测试权重为 0.1、0.2 的用例时通过了，但把权重改成 0.3、0.6 时却失败。原因很简单，浮点数二进制表示在某些小数上会有误差，0.1 + 0.2 的结果并不等于 0.3，而是约等于 0.30000000000000004。这个误差在数学上微不足道，但在断言比较时就是失败。解决方法是统一使用pytest.approx或math.isclose，并且设定一个合理的相对误差阈值。
成员顺序问题则更隐蔽。在某次修改中，我出于“优化”目的给递归入口加了一条“如果左侧已经达到总权重一半，则不再尝试右侧”的提前退出逻辑，理论上能大幅减少搜索量。测试跑了一天全绿，但随机化对拍测试偶尔会报错。排查后发现：提前退出依赖当前成员顺序，同一个集合，排列顺序不同，提前退出的时机就不同，最终方案也不同。这就是顺序无关性测试存在的意义。最后我把这条优化逻辑删掉，改用纯安全剪枝，问题消失。这个教训告诉我：优化的前提是保证行为语义不变，如果语义变了，那就不再叫优化，叫改变规则。
6.4 测试用例本身太脆弱
还有一个不太起眼但很重要的坑：我早期写的测试断言里直接检查了具体的成员分配方案，比如assert plan.left == ["小A", "小B"]。问题在于，当最优方案不唯一时，这个断言就变成了一颗定时炸弹——函数返回另一个同样最优的方案时，测试会失败，但函数本身并没有错。后来我把这类断言改成只检查 diff 和完整性约束，不再断言具体名单，测试就稳定多了。测试应该关注“行为是否满足契约”，而不是“内部实现细节是否符合我的预期”。这个认知转变，让我的测试维护成本降了一大截。
7. 写在最后：递归会结束，但思考不会
做这个项目最大的感受，不是学会了怎么用递归，而是理解了什么叫“把一个问题真正想清楚”。写递归函数的时候，你在思考子问题如何拆分、终止条件在哪里、状态如何收敛。写测试用例的时候，你在思考这个函数承诺了什么规则、哪些输入可能击穿它。做鲁棒性设计的时候，你在思考调用方会怎样误用这个函数、系统会在什么极端场景下崩溃。这种层层递进的思维训练，是单纯刷题给不了的。
我也要再说一遍，这个项目里的“抚养权分割”只是抽象建模，真实世界没有函数能在“谁跟谁更合适”这个问题上算出唯一最优解。但如果有一天你遇到一个真正的资源分配问题，无论是分机器、分流量、分钱、分时间，这套“递归建模 → 测试验证 → 鲁棒性加固”的方法论完全可以平移过去。代码里的递归会有终止条件，但思维上的递归不会轻易结束——你每解决一层问题，又会冒出一层新的问题需要继续拆解。这大概就是这个行业真正让人上瘾的地方。
