基数排序不能替代sort.ints，因其仅在百万级uint32/偏移int32且位数固定时快2–3倍；小数据、重复多或分布不均时更慢，且不支持float64、string或直接排结构体。
为什么直接用 sort.Ints 不能替代基数排序
基数排序不是“更快的 sort.Ints”，它是另一类算法：只在特定条件下有优势。当你面对百万级 []uint32 或已偏移的 []int32，且最大位数固定（比如全是 0–9999999 的整数），radixSort 才可能比 sort.Ints 快 2–3 倍；但一旦数据量小于 10k、含大量重复值、或分布极不均匀（如 99% 是 0），它反而更慢，还多占内存。
常见误判点：
- 看到 “O(n)” 就以为一定比 O(n log n) 快——实际常数项很大，小数组里
sort.Ints的 cache 局部性更好 - 拿它排
[]float64或变长[]string——会 panic 或结果错乱，因为基数排序不处理浮点语义，也不自动填充字符串 - 用它替代
sort.SliceStable排结构体——必须先提取整型 key 转成 slice，否则无法按位分桶
radixSortUint32 必须从最低字节开始循环
Go 中对 []uint32 做 LSD 基数排序，标准做法是循环 4 轮，每轮按一个字节（0–255）分桶。关键约束：shift 必须从 0 开始，即第一轮处理最低有效字节（LSB），顺序是 0 → 8 → 16 → 24。
错误示例：for shift := uint(24); shift >= 0; shift -= 8 —— 这会导致高位优先，破坏稳定性，相同高位的元素相对顺序会反转。
实操建议：
- 桶数组声明为
buckets := make([][]uint32, 256)，不要用map[byte][]uint32，后者每次 append 都触发哈希扩容 - 每轮结束后清空桶：用
for i := range buckets { buckets[i] = buckets[i][:0] }，复用底层数组，避免 GC 压力 - 若数据中 0x0000xxxx 占比超 70%，可预估各桶容量（如按历史直方图），用
make([]uint32, 0, approx)减少扩容次数
负数处理不能靠 math.Abs 简单转换
对 []int32 直接取绝对值再排序，会把 -1 和 1 都变成 1，丢失符号信息。正确做法是做符号位翻转：用 uint32(x) ^ 0x80000000 把二进制表示的补码整数映射为单调递增的 uint32 序列（即 IEEE 整数编码顺序）。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
这等价于把整个 int32 范围 [-2³¹, 2³¹) 映射到 uint32 的 [0, 2³²)，保持原有大小关系。
注意点：
- 别用
binary.LittleEndian.PutUint32—— 它是序列化操作，不产生数值映射 - 别用
float32bits—— 这是针对 float 的 bit 模式，对 int 无效 - 若要支持
[]int64，对应翻转是uint64(x) ^ 0x8000000000000000
桶计数阶段最容易越界的两个位置
几乎所有线上 panic 都出在这两处：
-
(arr[i] >> shift) & 0xFF：当shift >= 32时，Go 对 uint32 右移 ≥32 位返回 0，看似安全，但若误用于uint64且shift写成32而非56，就会漏掉高位字节 -
bucket[(arr[i]/significantDigit)%10]：这是十进制写法，仅适用于非负整数；一旦arr[i]为负，%10在 Go 中返回负余数（如-5 % 10 == -5），导致下标负溢出
真正健壮的写法是统一走字节分桶（& 0xFF），并确保 shift 步长和类型匹配：uint32 用 0/8/16/24，uint64 用 0/8/16/24/32/40/48/56。
最后提醒：findLargestNum 函数里变量名拼错成 laegeNum 或 largesNum 不会编译报错，但会让循环轮数恒为 0——这种 typo 在调试时极难发现。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
