np.unique(arr, return_counts=True)可同时返回唯一值和频次；默认展平统计，二维需指定axis；nan被统一视为相等；底层C实现比手动遍历快得多。
np.unique() 怎么同时拿到唯一值和频次
直接用 return_counts=True 参数，这是最常用也最稳的组合。不加这个参数，默认只返回去重后的数组，频次得自己手写循环统计，纯属绕路。
常见错误是以为要先调一次 np.unique() 拿值、再对每个值调 np.sum(arr == x)，不仅慢，还容易在浮点数或 NaN 场景下出错。
实操建议：
-
unique_vals, counts = np.unique(arr, return_counts=True)—— 两变量解包，顺序固定：第一个是值，第二个是对应频次 - 如果原数组是二维的（比如
shape=(100, 5)），默认会先展平再统计；要按行/列去重，得加axis=0或axis=1，但此时return_counts=True会报错（NumPy 1.24+ 已支持，旧版本不行） - 遇到
nan，注意np.unique()默认把所有nan当作相等处理，合并为一个nan值并统计总次数；但若数组含多个nan，它们在排序后会排在最后（且顺序不稳定）
为什么 np.unique(..., return_counts=True) 比手动 count 快
因为底层是 C 实现的哈希 + 排序双路径优化：先排序，再线性扫描计数，时间复杂度接近 O(n log n)，而手动遍历每个唯一值再全数组比对是 O(n²)，尤其在唯一值多时差距明显。
实操建议：
- 别用
[np.sum(arr == v) for v in np.unique(arr)]—— 看似简洁，实际重复扫描数组多次 - 如果只要频次、不要值本身，可以接续用
counts变量，别再从unique_vals里反查索引 - 小数组（
np.unique() 遇到浮点数去重不准怎么办
不是函数有问题，是浮点精度导致的“看起来相同、实际不同”。比如 0.1 + 0.2 不等于 0.3，np.unique() 会把它们当两个值。
实操建议：
- 提前做数值规整：用
np.round(arr, decimals=5)再传给np.unique()，decimals 根据业务精度定（金融常用 2，科学计算可能要 10+） - 避免用
np.isclose()后手工合并——没法直接喂给np.unique()，得自己写逻辑，易错且无向量化优势 - 如果必须保留原始浮点值，又想按“近似相等”分组，得换思路：用
scipy.spatial.distance.pdist或聚类，np.unique()不适合这种场景
返回的 counts 和 unique_vals 顺序怎么保证一致
完全一致，且按 unique_vals 的升序排列（字符串按字典序，复数按实部+虚部）。这是 np.unique() 的硬性约定，不用额外排序。
容易踩的坑：
- 误以为频次顺序和原数组中首次出现顺序一致 —— 实际是升序，比如输入
[3, 1, 2, 1]，输出unique_vals=[1,2,3]，counts=[2,1,1] - 想按频次降序排列？得自己用
np.argsort(counts)[::-1]索引重排两个数组，np.unique()不提供sort_by='count'这种参数 - 用
return_index=True或return_inverse=True时，别和return_counts=True混着解包，顺序是固定的：vals, idx, inv, cnts = np.unique(..., return_index=True, return_inverse=True, return_counts=True)，漏一个就会报错
return_counts=True，别绕。其它都是围绕它打补丁。 
