应使用 partition 而非新建切片：避免空间爆炸（o(n²)→o(1)）、确保原地修改、防止引用失效；pivot 选末尾因实现简单边界清晰；终止条件必须是 left >= right，而非 len(arr)；手写目的在掌握分区与递归控制，非替代 sort.ints。
为什么用 partition 而不是新建切片？
Go 中实现快排时，新手常直接照搬 Python 思路：每次选 base_num，再用 append 拼两个新切片——这看似清晰，实则隐含严重问题：空间爆炸、逃逸频繁、无法原地修改原数组。真实项目里你传进来的 arr 很可能被其他地方引用，新建切片后排序结果根本不会反映到原变量上。
- 新建切片方式（如
left_sli := []int{}）每次递归都分配新底层数组，O(n)额外空间，最坏递归深度O(n)→ 总空间O(n²) - 原地分区（
partition）只用两个游标i和j，交换元素，空间复杂度稳定O(1)，且能真正改写输入切片 - 若你确实需要不修改原数组，应显式
copy一份再传入，而不是在排序逻辑里偷偷重建
partition 函数里为什么选最后一个元素当 pivot？
选最后一个（arr[right]）不是因为“它最好”，而是因为实现简单、边界清晰、不易越界——尤其配合 left/right 双闭区间参数时，right 下标天然可用，不用额外计算或判断。
- 选第一个（
arr[left]）也行，但后续swap位置要改成arr[i]和arr[left]，容易漏改 - 选中间或随机 pivot 能缓解最坏
O(n²)情况（比如已排序数组），但需引入rand或额外计算，对多数业务场景属于过早优化 - 真正该警惕的是 pivot 选择后没把它的最终位置正确返回：必须确保
partition返回值是 pivot 的**最终索引**，否则递归调用quickSort(arr, left, pivot-1)会越界或漏排
递归终止条件写成 if left >= right 还是 if left >= len(arr)？
必须用 if left >= right。后者是典型错误——len(arr) 是整个切片长度，而你的递归始终在子区间 [left, right] 内操作，right 可能远小于 len(arr)-1，用全局长度会导致提前退出或 panic。
- 正确逻辑：子区间只剩 0 或 1 个元素时停止，即
left == right（1 个）或left > right（0 个）→ 合并为left >= right - 错误示例：
if left >= len(arr)在第一次递归就成立（因left=0,len(arr)>0），整个排序直接跳过 - 更隐蔽的坑：
if left == right会漏掉left > right的空区间情况，在某些 pivot 选择策略下可能触发无限递归
为什么不能直接用 Go 标准库的 sort.Ints 就完事？
你可以用，而且应该用——除非你在写算法题、教学代码、或需要定制分区逻辑（比如按绝对值排序、多关键字稳定划分）。但理解手写 quickSort 的关键不在“替代标准库”，而在掌握 partition 的边界控制和递归收缩方式。
-
sort.Ints底层确实是优化过的快排（带三数取中 + 小数组切换插入排序 + 尾递归优化），但它是黑盒；你调用它排不了自定义结构体，也看不到 pivot 如何移动 - 当你调试一个分治逻辑错乱的排序函数时，90% 的问题出在：分区后没把 pivot 放到最终位置、递归范围算错、或者
swap写反了左右操作数 - 真正难的不是“怎么写快排”，而是“怎么让
partition在任意输入下都返回合法索引，且左右子区间严格不重叠、不越界”——这点哪怕看十遍代码，不动手 swap 几次数组，也很难真正建立直觉
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
