<p>剪枝必须写在for循环条件里而非循环体内，因为前者能跳过无效分支、避免进入递归栈，后者仍会分配栈帧再退出；如combine(n,k)中，应设i <= n - (k - len(path)) + 1。</p>
Go 回溯剪枝不是“加个 if 就行”，关键在位置——必须写进 for 循环条件里，而不是塞进循环体开头。
为什么剪枝要放在 for 条件里，而不是 if 里？
因为位置决定是否进栈：写在 for i := start; i 的终止条件中（比如 <code>i ），循环根本不会启动；而写成 <code>if len(path) == k { return } 放在循环体内，函数已经分配了新栈帧、进了递归，再 return 只是白花开销。
- 典型错误：
for i := start; i target - sum { break } ... }——仍会执行循环体、调用递归 - 正确做法：
for i := start; i ——连循环都不跑 - 性能差异：前者可能多压几千栈帧，后者直接跳过整棵子树
combine(n, k) 的起始索引剪枝怎么算？
公式是 i ，意思是：“我还差 <code>k - len(path) 个数，那当前最多只能从位置 n - (k - len(path)) 开始选，否则后面没得填”。别硬记，拿 n=4, k=3, path=[1] 推一遍：还差 2 个，剩下位置只有索引 2 和 3（即元素 3、4），所以 i 最大取 2（0-based），即 i 。
- 循环写法：
for i := start; i - 注意边界：Go 切片访问是
[start:end]，end不包含，所以这个不等式用是安全的 - 如果用
，就得写成 <code>i ，容易出 off-by-one 错
数值类剪枝（如和超限）也必须进 for 条件？
是的，只要它能提前排除一整段连续索引，就该进条件。比如 candidates 已排序，那么一旦 candidates[i] > target - sum，后面所有 j > i 都无效——这正是 for 条件能拦住的范围。
立即学习“go语言免费学习笔记（深入）”；
- 错误示范：
if sum + candidates[i] > target { continue }—— continue 只跳本次，下轮 i 还会进 - 正确写法：
for i := start; i - 注意：这个判断依赖
candidates有序；无序时只能靠递归入口的sum > target终止，效率差很多
递归入口的终止判断和剪枝是两回事
剪枝拦的是“不该展开的分支”，终止判断拦的是“已经成型的无效路径”。两者缺一不可，但作用层级不同：剪枝在 for 条件里省掉子树，终止判断在函数开头防爆栈。
- 必须写的终止判断：
if sum > target { return }、if len(path) == k { res = append(res, append([]int(nil), path...)); return } - 漏掉这些，哪怕 for 剪枝再狠，也会在某层递归里触发
runtime: goroutine stack exceeds 1000000000-byte limit - 常见错觉：以为 for 剪枝够了，结果大输入下直接 panic
真正难的不是写对剪枝逻辑，而是分清“哪一步该拦在循环外、哪一步该拦在循环内、哪一步必须拦在函数开头”——三者混用或遗漏任意一个，都可能让算法从 AC 变成 TLE 或 panic。
