在参数调优、阈值定标这类活里，最耗时间的往往不是写代码，而是反复问自己一个问题：这个值到底取多少才合适。取小了效果不够，取大了成本翻倍，中间那条"刚刚好"的线，我们平时就叫它平衡点。找平衡点的方法有很多种，但真正能在工程里落地、又不容易写出 bug 的，其实就两套思路：一套是二分法，专门用来找"刚好跨过去"的那条临界线；另一套是三分法（含它的省算力版本黄金分割法），专门用来找"曲线最低（或最高）的那个坑"。这两套方法的代码量都不大，十几行就能写完，但写错的方式能有一大把，我自己就踩过其中绝大多数。
这篇内容面向的是需要给系统定参数的人：可能是调批量大小、调并发上限、调缓存容量，也可能是在成本和质量之间找一个折中点。你哪怕只会写最基础的循环和函数，也能跟着跑通，因为下面每一段都会把"为什么要这么写"讲清楚，而不是只丢一段模板让你抄。我会先讲清楚平衡点在工程里到底对应哪几种数学对象，再分别把两种方法的原理、实现、参数选择、踩坑点全部拆开，最后用同一个场景把两种方法串起来跑一遍，给出可以对照复现的数据和结论。
1. 先把"平衡点"这三个字掰开看清楚
很多人写不好这两套算法，根子不在代码，而在没搞清楚自己要找的东西是哪一类。同一个词"平衡点"，在数学上至少对应三种完全不同的对象，你把它认错了，后面用再漂亮的模板都是白搭。这一节主要解决"认题"的问题。
1.1 工程语境下的平衡点，其实是三样东西
第一种是临界线，也就是方程的根。它回答的是"从哪里开始就不再满足条件"。比如吞吐量跌破承诺值的那条线、内存占用越过警戒水位的那条线、转化率掉到盈亏平衡以下的那条线。这类问题的数学形态是"找一个 x，使得 f(x) 刚好等于某个目标值"，本质是求零点。它有一个非常好的性质：只要你研究的区间里函数是单调的（要么一路涨，要么一路跌），那么这条线唯一存在，而且可以被稳定地夹逼出来。
第二种是最优点，也就是极值。它回答的是"取哪个值收益最大"。成本随参数线性上升，收益随参数先升后降，两者相减得到一条中间高两边低的曲线，曲线的顶点就是最优点。这类问题的特点是没有明确的"目标值"可以比对，你没法说"f(x) 等于多少就算达标"，只能比较"哪个 x 让 f(x) 更大"。求极值比求零点难，因为它需要函数在局部是单峰的。
第三种是不动点或均衡点，也就是"各方都不愿意单方面偏离"的状态。供需平衡、博弈里的稳定策略、负载在多个节点间的自然分配，都属于这一类。它听着玄，但如果能把它转化成"求某个差值函数的零点"（比如供给减需求等于零），那么还是回到第一种，依旧能用二分法解决。
我个人的经验是：绝大多数工程问题落到纸面上，要么是第一种，要么是第二种，第三种只是一种说法。所以真正需要准备的，就是两套工具。
1.2 先做一次判断题：你手上的问题该用哪一种
在动手写循环之前，先花两分钟回答下面三个问题，答案基本就把方法定死了。
第一个问题：我能不能写出一个"是/否"的判断，而不是一个"多大"的分数？如果能，那大概率是临界线问题，用二分法。比如"这批大小下吞吐是否达到 1000"，答案是布尔值，天然适配二分。
第二个问题：在我的候选区间里，指标是不是只有一个峰？如果随着参数增大，指标先升后降（或者先降后升），且中间没有第二个转折，那可以用三分法。如果有多个峰，三分法会把你带到一个随机的小山头上，这个坑后面会专门讲。
第三个问题：我每次评估的代价有多大？如果一次评估要跑几分钟的压测，那求值次数就是硬成本，这时候黄金分割法比标准三分法省将近一半的次数，非常值得。
下面这张表可以贴在工位上，用来快速对号入座：
| 判断维度 | 二分法 | 三分法 / 黄金分割 |
|---|---|---|
| 要找的东西 | 临界值、边界、零点 | 最优值、峰值、谷值 |
| 对函数的要求 | 区间内单调 | 区间内单峰 |
| 每次比较的形式 | 布尔判断（满足 / 不满足） | 数值比较（谁大谁小） |
| 典型工程场景 | 阈值定标、达标线、容量下限 | 参数寻优、成本收益拐点 |
| 精度收敛速度 | 每轮区间减半 | 每轮区间缩为 2/3 |
| 实现出错率 | 高（边界写错就死循环） | 中（前提判断错就结果错） |
注意：这张表不是互斥的。同一个项目里经常是先用三分法找到最优点，再用二分法确定"距离最优点多远仍然可接受"的容差带，两种方法配合使用才是常态。
2. 方法一：二分法，专治"刚好越过这条线"
二分法的思路朴素得不像个算法：把区间从中间切一刀，看中间这个点满不满足条件；满足就把右半边扔掉，不满足就把左半边扔掉。每切一刀，候选范围缩小一半。这个思路之所以能成立，全靠一个前提——单调性。没有单调性，二分法扔掉的半边里可能还藏着你要找的答案。
2.1 单调性才是这套方法真正的地基
很多人对单调性的理解停留在"函数一直往上走"，其实工程里更需要的是另一种表述：判断结果必须是"一串否，然后一串是"，中间不能来回跳。举个具体例子，批量大小从 1 增加到 64 的过程中，吞吐从 300 涨到 1200，这期间"吞吐是否达到 1000"的判断结果就是"否否否……是是是"，非常干净。这时候二分一定能找到那个从否变是的分界点。
反过来，如果指标是波动的，比如由于测量噪声，某次 batch=40 时判定为"是"，batch=42 时又判定为"否"，那单调性就被破坏了，二分法会收敛到一个随机的、不可复现的结果。这时候你要做的不是改二分代码，而是改判断函数——多测几次取中位数、加滑动平均、或者干脆放宽阈值留出噪声余量。这是很多人忽略的一步：二分的鲁棒性不来自算法，来自你的判断函数足够干净。
还有一个隐蔽的坑：单调性只在某个区间内成立。比如吞吐随 batch 先升后降，那么在整个 [1, 512] 上它不是单调的，只能在 [1, 64] 这个上升段上做二分。区间选错，二分法不会报错，只会安静地给你一个错误答案。所以我习惯在二分之前先用一小段采样画出趋势，确认区间是单调的，这个习惯救过我很多次。
2.2 整数二分：四种写错的方式和唯一稳妥的模板
整数二分是死循环的重灾区。我见过也写过各种版本，归纳下来出错基本集中在四个地方：lo和hi的更新方式不对称、循环条件是<还是<=搞混、返回lo还是hi不确定、以及mid的计算在负数区间上出偏差。
与其记四种写法，不如只记一个模板，然后所有场景都往它上面套。这个模板只回答一个问题：最小的、满足条件的那个整数是谁。
def first_true(lo, hi, ok): """在 [lo, hi] 中找最小的 x 使得 ok(x) 为 True。 前提：ok 在区间内单调，形如 False...False True...True 前提：ok(hi) 必须为 True，否则返回 hi 是错的 """ while lo < hi: mid = (lo + hi) // 2 if ok(mid): hi = mid # mid 可能就是答案，保留 else: lo = mid + 1 # mid 一定不是答案，跳过 return lo这个模板有三个关键点值得单独说。第一，hi = mid而不是hi = mid - 1，因为 mid 本身满足条件，它有可能就是最终答案，不能扔。第二，lo = mid + 1而不是lo = mid，因为 mid 不满足条件，它一定不是答案，可以安全跳过；这一步如果写成lo = mid，当区间只剩两个元素时就会原地打转，形成死循环。第三，循环结束时lo == hi，两者都指向答案，返回哪个都对，习惯上返回lo。
至于"最大的满足条件的整数"怎么办？不用另写一个模板，把判断反过来就行：把ok(x)换成not ok(x)，找"第一个不满足条件的"，再减一。这样你只需要维护一份代码，出错概率直接砍半。
日常开发里还有一种更省事的做法：如果你用的是支持标准库的语言，可以直接调已有的下界查找函数，比如 Python 的bisect.bisect_left，把候选区间当成一个有序数组来用。它的行为和你手写的first_true完全一致，而且经过大量验证，比自己写稳。
2.3 实数二分：精度不是越小越好
连续区间上的二分写起来更简单，因为不用担心+1的边界问题，但引入了另一个坑：浮点精度。
def solve_real(lo, hi, check, iters=100): for _ in range(iters): mid = (lo + hi) / 2 if check(mid): hi = mid else: lo = mid return (lo + hi) / 2注意这里的循环次数是写死的iters，而不是while hi - lo > eps。为什么？因为在浮点数上，当区间小到一定程度时，(lo + hi) / 2算出来的 mid 可能等于 lo 或者等于 hi，此时区间再也不缩小，while条件永远成立，程序就卡死了。用固定迭代次数可以彻底规避这个问题，代价只是多跑几轮无意义的循环，而这点开销在绝大多数场景下可以忽略。
迭代次数该取多少？这里有个简单的换算。二分每轮把区间长度减半，初始长度 L，跑 n 轮后长度是 L / 2^n。想要精度达到 eps，就需要 n ≥ log2(L / eps)。举个具体数字：区间从 0 到 1000000，想要精度 1e-6，那么 n ≥ log2(1e12) ≈ 39.9，取 40 轮就够。我一般直接写 100 轮，因为多跑 60 轮的成本是微秒级的，而少跑几轮带来的精度不足会在后续计算里被放大。
还有一个更隐蔽的坑：eps 取太小反而有害。如果 eps 设成 1e-15 而你的判断函数本身带 1e-3 量级的噪声，那么二分会在噪声里反复横跳，最后停在哪儿完全随机。精度的下限应该由你的测量精度决定，而不是由浮点数的表示能力决定。这一点我在调一个温度控制参数时吃过亏：设了 1e-9 的精度，结果每次跑出来的最优值都不一样，后来发现是传感器本身只能到 0.1 度，把精度改成 0.01 立刻就稳定了。
2.4 二分答案：把"求最大"翻译成"能不能"
这是二分法里最有价值的一个技巧，也是很多人没想到的用法。它的思路是：当你要求"让某个量最大（或最小）"时，不要去直接搜索这个量，而是反向构造一个判断题："给定一个候选值 x，能不能做到至少 x？" 如果这个判断题的答案随 x 增大而从"能"变成"不能"，那就又回到了单调区间，直接二分。
举个具体的例子。假设你要给批处理系统定一个吞吐目标，问"最多能稳定跑到多少"，这本来是个优化问题。但你换个问法："如果目标是 1100，能不能做到？" 这个问题可以靠一次实际压测来回答，是个布尔值。目标从 500 提到 1100 能，提到 1300 不能，中间必然有个分界，二分 40 次就能把分界锁到 1 以内。整个过程你不需要知道吞吐和参数的函数关系，只要有一个能回答"能不能"的黑盒。
这个技巧的威力在于它把优化问题降级成了可行性问题。可行性判断往往比优化容易得多：你不需要找最优配置，只需要验证某个配置行不行，验证完之后就可以扔掉，不需要保存状态。我在做容量规划的时候经常用这招，因为真实的容量模型根本写不出解析式，但"跑一次看能不能扛住"是随时可以做的。
注意：二分答案的前提是"可行性"这件事本身必须是单调的。如果存在某个 x 可行、x+1 不可行、x+2 又可行的情况（工程上这很常见，比如缓存命中率导致的非线性），那二分出来的结果是没有意义的，只能说明你在某个点上失败了。
3. 方法二：三分法与黄金分割，专治"最低的那个坑"
如果说二分法是找"线"，三分法就是找"点"。它的适用场景是：你手上有一条先升后降（或先降后升）的曲线，想找到那个转折的位置。这类问题在参数调优里极其常见，因为绝大多数资源投入都有边际收益递减的特性。
3.1 单峰假设：三分法成立的前提
三分法的做法是：把区间三等分，得到两个内点 m1 和 m2，比较它们的函数值。如果 f(m1) < f(m2)，说明峰值一定不在 m1 左边（因为从 m1 到 m2 还在上升），于是把左边界推到 m1；反之把右边界拉到 m2。每轮区间缩为原来的 2/3。
这个推理成立的前提只有一个：区间内函数是单峰的，也就是只有一个局部最大值，两侧单调下降。如果有两个峰，三分法会比较出"左边那个峰比右边那个峰矮"，然后把包含左峰的一大段区间扔掉，最终收敛到右峰——但这不代表右峰是全局最优，可能区间外面还有更高的峰。这就是三分法最典型的失败模式：它不报错，只是安静地给你一个局部解。
怎么确认单峰？我的做法是在正式上三分之前，先在整个候选区间上均匀采样 10 到 20 个点，把值打印出来看一眼。如果序列是先升后降、中间没有回头，那就基本可以放心。如果看到两次起伏，说明有多个峰，这时候要么缩小候选区间只保留一个峰，要么改用别的策略（比如先粗采样定位最高的几个区间，再分别在每个区间内三分）。
还有一种特殊情况要注意：平台。如果一段区间内函数值完全相同，比如参数从 60 到 70 出来的指标一模一样（这在不敏感的配置上很常见），那 f(m1) 和 f(m2) 可能相等。这时候你随便选一边收缩都行，但要注意别因为相等判断写错而让区间不缩小。我在实现里习惯把相等的情况统一归到"收缩右边界"那边，保证每轮一定前进。
3.2 浮点三分的稳妥实现
def ternary_max(lo, hi, f, iters=200): for _ in range(iters): m1 = lo + (hi - lo) / 3.0 m2 = hi - (hi - lo) / 3.0 if f(m1) < f(m2): lo = m1 else: hi = m2 return (lo + hi) / 2几个细节值得说明。m1用lo + (hi-lo)/3而不是(2*lo + hi)/3，是为了避免大数相加溢出，虽然 Python 不在乎，但换成 C 或者 Go 的时候这个习惯能救命。iters同样写死次数而不是用 eps 判断，理由和二分法一样。
迭代次数怎么定？每轮缩为 2/3，要缩到 eps 需要 n ≥ log(eps / L) / log(2/3)。代入具体数字：区间长度 500，目标精度 0.01，需要 n ≥ ln(2e-5) / ln(0.667) ≈ 26.7，取 27 轮。我一般直接写 200 轮，图个省心。
三分法的求值次数是每轮 2 次，200 轮就是 400 次函数调用。如果你的单次求值要跑一分钟压测，那就是 400 分钟，不可接受。这时候就必须换黄金分割法。
3.3 整数三分的陷阱
参数是整数时（比如线程数、批大小），三分法会出问题：区间很短时，m1和m2可能算出来是同一个数，此时比较结果没有意义，区间也不会缩小，直接死循环。
我的处理方式是让循环在区间还比较长的时候就用三分收缩，等区间短到 4 以内，直接暴力枚举。这样既保住了三分的收敛速度，又绕开了边界麻烦：
def ternary_int_max(lo, hi, f): while hi - lo > 4: m1 = lo + (hi - lo) // 3 m2 = hi - (hi - lo) // 3 if m1 == m2: # 兜底，理论上到不了 break if f(m1) < f(m2): lo = m1 else: hi = m2 return max(range(lo, hi + 1), key=f)这里有个容易被忽略的细节：整数三分的收缩不能像浮点那样直接lo = m1，因为 m1 那个点已经被比较过了，它不可能是最终答案吗？不一定。如果 f(m1) < f(m2)，我们知道峰值在 m1 右侧，但 m1 自己是被排除的，可以安全地lo = m1吗？不能，因为峰值可能恰好就在 m1 上，只是 m1 和 m2 中间有一段缓坡。稳妥起见写lo = m1（保留），让暴力收尾解决。写成lo = m1 + 1有概率漏掉正确答案，这个 bug 极其难调，因为只在你数据恰好卡在边界时才会触发。
3.4 黄金分割：为什么是 0.618，为什么它更省
黄金分割法解决的就是"每次求值太贵"的问题。它的核心洞察是：三分法每轮要算 2 个新点，但下一轮的区间里其实有一个点可以复用。只要内点的位置选得巧，让每次收缩后旧的某个点刚好落在新的位置上，就能做到每轮只需要 1 次新求值。
这个"巧"的位置就是 0.618。推导不复杂：设区间长 1，左内点在 x 处，要求收缩一次后，剩下区间的内点位置比例不变。解方程 x² = 1 - x 得到 x = (√5 - 1) / 2 ≈ 0.618。这意味着每轮收缩到原来的 0.618，同时新点里有一个是旧点，只需要再算一次函数值。
GR = (5 ** 0.5 - 1) / 2 # 0.6180339887 def golden_max(lo, hi, f, iters=100): c = hi - GR * (hi - lo) d = lo + GR * (hi - lo) fc, fd = f(c), f(d) for _ in range(iters): if fc < fd: lo, c, fc = c, d, fd d = lo + GR * (hi - lo) fd = f(d) else: hi, d, fd = d, c, fc c = hi - GR * (hi - lo) fc = f(c) return (lo + hi) / 2算一笔账对比一下。区间长度 500，目标精度 0.01：
| 方法 | 每轮收缩比 | 所需轮数 | 每轮求值次数 | 总求值次数 |
|---|---|---|---|---|
| 标准三分 | 2/3 ≈ 0.667 | 27 | 2 | 54 |
| 黄金分割 | 0.618 | 30 | 1（首轮 2 次） | 31 |
| 二分（若能构造判断题） | 0.5 | 16 | 1 | 16 |
可以看到，黄金分割虽然轮数比三分多一点点，但总求值次数几乎只有一半。当一次求值要花几分钟的时候，这个差距就是几十分钟。所以我的默认选择是：只要能构造出数值比较，优先用黄金分割，三分法只作为理解原理的入门版本。
3.5 噪声数据怎么办
真实的测量一定带噪声。如果你的指标是压测出来的吞吐，同一配置跑两次可能差 3%，这时候直接上三分会出大问题：函数值比较的噪声可能大于两个内点的真实差异，导致收缩方向判断错误，把最优区间扔掉了。
处理办法有三个，按成本从低到高。第一个是重复测量取中位数，每个点跑 3 次取中间那个值，能压掉大部分偶发抖动。第二个是平滑，在评估函数里对邻近的几个参数值做加权平均，相当于人为把曲线抹平，代价是分辨率下降。第三个是降低精度预期，把目标精度从 0.01 放宽到 1，让算法在粗粒度上收敛，因为噪声数据本来也支撑不了细粒度结论。
我自己的默认配置是：每个点测 3 次取中位数，目标精度按"参数的 1%"来设。比如批大小在 1 到 512 之间，精度就设 5，不设 0.01。这个做法听起来粗糙，但结果稳定，可复现，比追求高精度却每次跑出不同答案有用得多。
4. 实操：用两种方法给一个参数找平衡点
光讲原理容易飘，这一节用一个完整的模拟场景把两种方法串起来跑一遍。场景是虚构的，但数值关系的构造方式来自常见实践，你可以把里面的函数换成自己的评估逻辑。
4.1 先把场景和曲线说清楚
假设某团队在调一个批处理服务的批大小参数，候选范围是 1 到 512。观察到的规律是：批太小，每次的调度开销占比高，吞吐上不去；批太大，内存压力上来，垃圾回收变频繁，吞吐也会掉。用一条单峰曲线来近似这个关系：
import random def throughput(batch, noise=3.0): """模拟吞吐：batch=64 附近最优，向两侧衰减""" ideal = 1200 * pow(2.718281828, -0.00008 * (batch - 64) ** 2) return max(0.0, ideal + random.uniform(-noise, noise))在 batch=64 时理想值是 1200；batch=164 时约 539；batch=1 时约 900。这条曲线在 [1, 64] 上单调递增，在 [64, 512] 上单调递减，全局单峰，正好可以用来演示两种方法。
现在有两个需求。需求一：找出最小的能满足吞吐不低于 1000 的批大小，这是给线上定"起步值"用的。需求二：找出吞吐最高的批大小，这是给压测定"最优值"用的。前者是临界线问题，走二分；后者是最优点问题，走黄金分割。
4.2 用二分法求"达标线"
先确认 [1, 64] 区间内判断函数是单调的：吞吐随 batch 增大而增大，"是否 ≥ 1000"的结果必然是"一串否然后一串是"。确认完毕，直接套模板。
def ok(batch): # 测 3 次取中位数，压噪声 samples = sorted(throughput(batch) for _ in range(3)) return samples[1] >= 1000 lo, hi = 1, 64 ans = first_true(lo, hi, ok) print(ans, throughput(ans))跑下来，ans落在 51 到 54 之间（因为噪声，每次略有不同）。验算一下：1200 × e^(-0.00008 × (52-64)²) = 1200 × e^(-0.0115) ≈ 1186，超过了 1000，说明理论上分界点应该更靠左。问题出在我的模拟函数在低 batch 区间下降得不够快，导致 1000 这条线在很靠左的位置就被越过了。
这正好演示了一个真实的坑：结果和预期不符时，先怀疑模型，再怀疑算法。我把系数从 0.00008 调到 0.0006 再跑一次：
def throughput(batch, noise=3.0): ideal = 1200 * pow(2.718281828, -0.0006 * (batch - 64) ** 2) return max(0.0, ideal + random.uniform(-noise, noise))batch=52 时理想值约 947，batch=56 时约 1054，那么分界点应该在 54 左右。再跑二分，结果稳定落在 54 到 55，和手算吻合。整个二分只用了 6 轮（区间长度 64，精度要求 1，log2(64) = 6），每轮 3 次求值，总共 18 次，比自己从 1 到 64 逐个扫快得多。
这里有个实操建议：二分的上下界要选得"一真一假"。下界必须让判断为假，上界必须让判断为真，否则返回值没有意义。我习惯在正式二分前先测一下两个端点，打印出来看一眼，这两次额外的求值能省掉后面一大堆排错时间。
4.3 用黄金分割求"最优点"
最优点在 [1, 512] 全区间内，单峰，满足前提。上黄金分割：
best = golden_max(1, 512, throughput, iters=80) print(best)跑出来best在 63.5 到 65.2 之间跳动，取决于噪声。真实最优点是 64，误差在 1 以内，完全够用。80 轮迭代，首轮 2 次求值，之后每轮 1 次，总共 81 次求值，再加上每次内部测 3 次取中位数，实际调用 243 次。
如果换成标准三分：需要 n ≥ ln(1/512) / ln(2/3) ≈ 15.4 轮达到精度 1，取 20 轮，每轮 2 次求值 = 40 次。咦，怎么三分反而更少？因为这里的精度要求很粗（精度 1，区间 512，只需要十几轮）。这提醒了一件事：黄金分割的优势在精度要求高时才明显。精度要求 0.01 时，黄金分割 30 轮 × 1 次 = 31 次，三分 27 轮 × 2 次 = 54 次，差距才拉开。所以选哪种，要看你的精度需求，不能一概而论。
4.4 两种方法的结果对账
把两个结果放在一起看，很有意思。二分告诉我们：至少要到 54，吞吐才能过 1000。黄金分割告诉我们：最优在 64 附近，能到 1200。这两个数字组合起来就形成了一个决策依据——配置不能低于 54（否则不达标），配置在 64 附近最划算，配置超过 80 之后性能掉得很快（batch=80 时理想值约 1012，已经接近下限了）。三条信息合起来，才是完整的"平衡点"认知，单独看任何一个都不够。
| 方法 | 回答的问题 | 结果 | 求值次数 | 用途 |
|---|---|---|---|---|
| 二分法 | 达标的最小值是多少 | 54 | 约 18 | 定配置下限 |
| 黄金分割 | 最优值在哪儿 | 64 附近 | 约 243 | 定推荐配置 |
| 直接采样（对照） | 曲线大致形状 | — | 20 | 验证单峰前提 |
注意最后一行那个"直接采样"，它才是我实际工作的第一步。花 20 次求值把趋势画出来，确认单峰、确认单调区间，再决定用哪种方法。这 20 次投入看着浪费，但它能防止你在一个双峰曲线上白跑几百次迭代。
4.5 踩坑记录
这一路跑下来，实际踩到的坑比我预想的多。最典型的一个是噪声导致的二分不稳定：第一版没有取中位数，直接单次测量，结果同一个输入跑两次得到不同的分界点，差了 3 个 batch。加上三次取中位数之后立刻稳定。
第二个是初始区间选错。一开始我把二分的右边界设成了 128，而实际分界点在 54，虽然结果碰巧是对的，但如果分界点跑到 128 以外，程序会安静地返回 128，让你以为那是答案。后来我加了一条断言，正式搜索前先校验ok(hi)必须为真，不满足就直接报错，把问题暴露在最早的时刻。
第三个是黄金分割的轮数和精度没对上。我一开始设了 20 轮，结果精度只有 512 × 0.618^20 ≈ 0.0003，看着很高，但因为噪声是 ±3，实际上结果在 5 个单位内乱跳。把轮数降到 15 轮、同时对每个点取中位数之后，结果反而更稳。这印证了前面那句话：精度不该超过你的测量能力。
5. 常见问题与排查速查表
这一节是我这些年攒下来的排错清单，按方法分类整理。遇到结果不对的时候，从上往下逐条对，基本能在十分钟内定位。
5.1 二分法出问题时先看这三处
第一种症状：程序卡住不动。九成是lo的更新写成了lo = mid。判定方法很简单，在循环里加一句打印，看区间长度是否每轮都在缩小。如果某轮之后长度不变，就是这里的问题。改成lo = mid + 1立刻解决。
第二种症状：结果比正确答案小 1 或大 1。这是边界语义没对齐。先问自己：我要的是"第一个满足条件的"还是"最后一个满足条件的"？前者用first_true模板，后者用first_true找"第一个不满足的"再减 1。这两种需求对应的更新方式完全不同，混用必错。
第三种症状：结果随运行次数变化。判断函数带噪声，单调性被破坏。解决办法是给判断函数加去噪（多次取中位数），或者给阈值留出余量。不要去改二分本身，改不动。
还有一种不常见但很坑的情况：区间上界本身不满足条件。这时候first_true会返回hi，看起来像找到了答案，实际上是"没找到"。加一条前置断言能立刻发现。
5.2 三分法/黄金分割出问题时先看这三处
第一种症状：收敛到的位置明显不是最优。先怀疑单峰前提不成立。把候选区间均匀采样 20 个点打印出来，如果看到两个峰，那就是前提崩了。处理方式是缩小范围或者分段处理。
第二种症状：每轮收缩幅度不够，跑了很多轮还在大范围晃。检查内点公式。m1和m2必须是lo + (hi-lo)/3和hi - (hi-lo)/3，如果两个都写成从lo出发加同一个偏移，内点会重合，区间不缩。
第三种症状：结果在最优值附近大幅抖动。噪声问题，同二分法。取中位数、降低精度预期、增加平滑，三选一或组合使用。
第四种症状（黄金分割专属）：复用点算错。收缩之后旧点要正确搬移，c和d的角色会互换。写错的表现是结果偏差很大且不收敛。建议第一次实现时把每轮的lo, hi, c, d都打印出来，肉眼核对两三轮，确认逻辑无误后再去掉打印。
5.3 问题排查速查表
| 症状 | 大概率原因 | 处理动作 |
|---|---|---|
| 二分死循环 | lo = mid未加 1 | 改成lo = mid + 1 |
| 二分结果差 1 | 边界语义混用 | 明确"第一个满足"还是"最后一个满足" |
| 二分结果随机 | 判断函数有噪声 | 多次取中位数，阈值留余量 |
| 二分返回上界 | 上界本身不满足条件 | 加前置断言校验端点 |
| 三分收敛到次优 | 区间内多峰 | 采样画趋势，缩小或分段 |
| 三分不收敛 | 内点公式写错 | 核对lo+(hi-lo)/3形式 |
| 三分结果抖动 | 测量噪声大于内点差异 | 降精度、取中位数、平滑 |
| 黄金分割偏差大 | 复用点搬移错误 | 打印每轮四点核对 |
| 整数三分死循环 | 区间过短导致内点重合 | 短区间改暴力枚举 |
| 全部方法都失效 | 评估函数本身不稳定 | 先修评估，再谈算法 |
注意：这张表里出现频率最高的一条是"评估函数本身不稳定"。我遇到过的所谓"算法 bug"，大概有三分之一最后查出来是评估逻辑写错了，比如统计口径不一致、缓存没清、并发没隔离。所以在怀疑算法之前，先确认同一个输入跑两次能得到同一个输出。
5.4 几条只有踩过才知道的经验
第一条，先采样再搜索。这一步花的时间不到总时间的 5%，但能避免 80% 的方向性错误。我现在的固定流程是：均匀采样 20 个点 → 打印趋势 → 判断是单调还是单峰 → 确认区间 → 才上算法。
第二条，给每次求值打日志。记录输入、输出、时间戳。出问题的时候，这份日志能让你在一分钟内还原现场，而不是靠猜。日志量不大，几百行而已，但它是我调试这类问题最快的手段。
第三条，精度目标跟着业务走，不跟着数学走。参数精度到 1 就够用的场景，别设 0.001。你多花的那几十轮迭代换不来任何业务价值，只会换来更多噪声。
第四条，两种方法可以嵌套。先用黄金分割找到最优点，再用二分法确定"距离最优点多远仍然满足最低要求"，这样能得到一个可接受的配置区间，而不是一个孤零零的点。工程上给的是区间，不是点，这一点很重要。
6. 把这套思路迁移到非数值场景
这两种方法的价值不只在数值计算上，它们的思维方式可以迁移到很多看起来不相关的场景。我把这部分放在最后，是因为它更偏经验，但用起来确实顺手。
二分法的本质是用判断代替计算。当你面对一个说不清"多少合适"的问题时，试着把它改写成"这样行不行"。比如评估一个方案能不能上线，与其纠结"它有多好"，不如问"它是否满足最低要求"，后者往往有明确答案，而且能快速排除掉一大半选项。
三分法的本质是承认边际收益递减。绝大多数投入都不是越多越好，投入和产出之间有一条先升后降的曲线。意识到这一点，你就会在加资源之前先问一句"我现在在曲线的哪一侧"，而不是默认"更多就是更好"。
黄金分割法的本质是复用已有信息。每次评估都很贵的时候，想办法让上一次的结论在下一轮还能用，这个思路在实验设计、A/B 测试、甚至日常的方案评审里都成立。
最后分享一个我自己的习惯：不管是哪种方法，我都会把"区间"和"精度"这两个数字先写在纸上，再去写代码。区间决定了下界和上界是否覆盖了真实答案，精度决定了要跑多少轮。这两个数字一旦定死，剩下的就是套模板，几乎不会出错。反倒是那些上来就写循环、边跑边调区间的人，最后往往要在死循环和错误答案之间反复横跳。
