计数排序的空间效率取决于变量范围是否可控：范围过大导致内存爆炸、缓存失效和初始化开销；负数或动态范围需偏移处理，增加时间与空间成本；稀疏分布造成空间浪费；流式场景中边界模糊则难以预分配。

计数排序确实能用空间换时间，但这个“换”不是无条件的。关键在于变量范围（即最大值与最小值之差）是否可控——它直接决定辅助数组大小，进而影响内存占用和实际运行效率。

变量范围过大导致空间爆炸

假设你有一组 10 万个整数，数值分布在 0 到 99999999（1 亿）之间。按标准实现，需创建长度为 1 亿 + 1 的计数数组，哪怕只存 10 万个有效值，也要占用约 400MB 内存（int 占 4 字节）。这不仅浪费，还可能触发系统内存压力甚至 OOM。

• 若 k（范围）远大于 n（元素个数），空间复杂度 O(k) 成为主导，反而拖慢整体性能
• 缓存局部性变差：大数组无法全部装入 CPU 高速缓存，频繁访问内存会显著拉低速度
• 初始化开销不可忽略：新建并清零一个上亿长度的数组本身就要耗时

变量范围不确定或含负数时需额外处理

原始计数排序默认下标从 0 开始，只支持非负整数。遇到负数（如 -50 到 80）或动态范围（如实时采集的传感器数据），必须先做偏移校正。

• 需遍历一次原数组求 min 和 max，增加 O(n) 时间成本
• 计数数组长度变为 max − min + 1，若 min = −10000、max = 10000，则数组长度达 20001，尚可接受；但若 min = −500000、max = 500000，长度就超百万
• 所有索引访问都要做 arr[i] − min 运算，引入额外计算开销，虽小但批量累积可见

稀疏分布让空间严重低效

即使范围看似不大，但若数据极度稀疏，也会造成大量“空槽”。例如，1000 个数，范围是 1–10000，但实际只出现 100 个不同值，其余 9900 个下标对应计数全为 0。

• 统计数组中 99% 的空间未被利用，纯属冗余
• 后续遍历统计数组恢复结果时，要扫过大量 0 值位置，时间复杂度仍为 O(k)，而非 O(n)
• 此时用哈希表替代固定数组（如用 map 统计频次）反而更省空间，但会失去 O(n+k) 的严格线性保障

范围边界模糊时难以预分配

在流式处理或嵌入式场景中，你可能无法预先知道输入的最大最小值。比如接收实时日志中的响应码（HTTP 状态码理论上 100–599，但某次误传了 -1 或 9999）。

• 静态分配易越界或浪费；动态扩容又破坏线性时间特性
• 安全起见常按保守估计（如 0–65535）分配，但一旦实际数据突破该范围，算法直接失效或需重跑
• 工业级实现往往加一层范围校验 + fallback 机制（如超出阈值自动切换为快排），但这已脱离纯计数排序范畴