桶排序需手写，因标准库未提供；核心是合理分桶、负数偏移、小桶用插入排序、预分配合并，且仅适用于均匀分布数据。
桶排序在 Go 里不是“拿来即用”，得自己写
Go 标准库 sort 包不提供桶排序，它只内置了快排、堆排和插入排序的组合（sort.Slice 等）。所以你要用桶排序，就得手写逻辑——这不是缺陷，而是设计使然：桶排序高度依赖数据分布，通用实现反而容易误导。
常见错误现象：bucketSort([]int{1, 100, 50}) 直接 panic，因为没处理 minVal > maxVal 的边界（比如空切片或单元素），或除零（bucketSize == 0）。
- 必须先遍历一次找
minVal和maxVal，不能假设数据非负或已知范围 - 桶数量别硬写死成
10或len(arr)；合理值是(maxVal - minVal) / bucketSize + 1，其中bucketSize建议设为10～50（小数组用小值，大数组可略增） - 如果
minVal是负数，映射索引会越界，得先做偏移：用arr[i] - minVal再除以bucketSize
桶内排序选 insertionSort 而不是 sort.Ints？
对每个桶单独排序时，用标准库 sort.Ints 看似省事，但实际浪费：小桶（比如平均 3～5 个元素）用快排/堆排的常数开销远大于插入排序。实测在 n ≤ 20 时，insertionSort 比 sort.Ints 快 2～3 倍。
使用场景：桶内元素少且局部有序概率高（比如浮点数分桶后，同一桶内值接近），插入排序的自适应性就体现出来了。
立即学习“go语言免费学习笔记（深入）”；
-
insertionSort实现简单，6 行内搞定，无额外依赖 - 别对空桶或单元素桶调用排序函数，直接跳过
- 如果桶特别大（比如 > 100 元素），可降级为
sort.Ints，但这种情况说明桶划分失败，该先检查bucketSize是否太小
bucketSort 的致命坑：数据不均匀时性能雪崩
桶排序号称 O(n)，前提是数据**均匀分布**。一旦所有元素挤进同一个桶（例如排序 []int{5, 5, 5, 5} 或 []int{1, 2, 3, 1000000}），就退化成单次 O(n²) 插入排序，比 sort.Ints 还慢。
性能影响：你无法靠算法本身检测分布是否均匀，只能靠输入前验判断。
- 适用场景明确：日志时间戳（秒级）、传感器采样值（带宽有限）、ID 分段（如 user_id % 100）、归一化后的浮点特征
- 完全不适用：加密哈希值、递增主键 ID、含大量重复值的枚举字段
- 上线前务必用真实数据集压测，对比
sort.Ints耗时；若波动超过 2×，就换回标准排序
合并结果时别用 append 反复扩容
把各桶结果拼回原数组时，新手常写 result = append(result, bucket[i]...)，导致多次底层数组复制。Go 切片的 append 在容量不足时会重新分配，最坏 O(n²) 时间。
正确做法：预分配目标切片，用 copy 填充。
- 先算总长度：
total := 0; for _, b := range buckets { total += len(b) } - 声明
result := make([]int, total)，再用游标k累加写入：copy(result[k:], b); k += len(b) - 如果要求原地排序（修改输入切片），直接往
arr写，避免额外内存分配
桶排序真正的复杂点不在代码长短，而在你得时刻问自己：这批数据，真的适合分桶吗？分布偏斜、范围不明、样本量小——这些都不会报错，但会让算法悄悄变慢。写完别急着封装，先拿三组真实数据跑一遍对比。
