布尔索引本身不改变维度，但因条件数组形状不匹配（如布尔数组长度≠被索引轴长度）或混用花式索引，易导致意外降维或报错；正确做法是确保布尔数组长度匹配对应轴、慎用 np.ix_ 处理多维选择、用 None 扩展维度而非 keepdims。
用 np.array 做布尔索引时，为什么结果维度突然变了？
布尔索引本身不改变维度，但容易因条件数组形状不匹配导致意外降维或报错。比如对二维数组 a 写 a[a[:, 0] > 5] 是合法的——它返回所有满足第一列大于 5 的行，结果仍是二维；但若误写成 a[a[0] > 5]，就可能触发 NumPy 的“花式索引广播规则”，返回一维结果，甚至抛出 IndexError: boolean index did not match indexed array。
- 确保布尔数组长度等于被索引轴的长度（如筛选行，布尔数组长度必须等于
a.shape[0]） - 避免混用布尔索引和整数索引：像
a[a[:, 0] > 5, 1]是 OK 的（取满足条件的行的第 2 列），但a[a[:, 0] > 5, [0, 2]]会触发花式索引，返回 (n, 2) 形状，不是直觉上的“子矩阵” - 调试时先单独打印布尔数组：比如
mask = a[:, 0] > 5，再检查mask.shape和mask.sum()
用整数索引数组选多行多列，np.ix_ 为什么不能省？
直接写 a[[0, 2], [1, 3]] 返回的是两个标量：a[0,1] 和 a[2,3]，不是你想要的 2×2 子块。要真正选出行索引与列索引的笛卡尔积，必须用 np.ix_ 包装。
-
a[np.ix_([0, 2], [1, 3])]→ 返回 shape=(2, 2) 的子数组，等价于手动切片a[0:3:2, 1:4:2]但更灵活 -
np.ix_本质是把一维索引数组转成能广播的二维网格：它返回(row_indices[:, None], col_indices[None, :]) - 不使用
np.ix_而改用np.take或np.take_along_axis也可以，但语义更绕，且后者要求 axis 明确、输入排序逻辑清晰，易出错
筛选后想保留原始维度，keepdims=True 在哪起作用？
keepdims=True 只对聚合函数（如 np.sum、np.max）有效，对索引操作完全无效。想保留维度，得靠索引本身带括号或扩展维度。
- 错误做法：
a[a[:, 0] > 5, :].sum(axis=0, keepdims=True)—— 这里keepdims确实让结果变成 (1, n)，但它是聚合后的，不是索引时保留的 - 正确做法：用
np.newaxis或None扩展维度，例如a[a[:, 0] > 5][None, ...]（加一批维度），或筛选前就用a[np.newaxis, ...]预留空间 - 更自然的方式是用布尔索引配合
reshape：比如已知最多选 10 行，可预分配result = np.empty((10, a.shape[1]))，再赋值，避免动态 shape 变化影响下游
用 np.where 获取索引再筛选，比直接布尔索引慢多少？
慢 2–5 倍，且多占内存。因为 np.where(mask) 先生成两个长数组（行号、列号），再用它们做花式索引，而布尔索引是原地 mask 扫描，C 层优化充分。
立即学习“Python免费学习笔记（深入）”；
- 只在需要显式索引位置时才用
np.where：比如要记录哪些行被选中、后续要复用这些下标、或要做“按序号跳过第 N 个”的逻辑 - 常见误用：
a[np.where(a > 0)]完全等价于a[a > 0]，但前者多一次内存分配和解包 - 性能敏感场景（如循环内、大数据量），优先用布尔索引；调试时想看具体下标，再补一句
np.where(mask)
np.ix_ 的配合时机，都是线上 debug 时最常卡住的地方。别依赖“看起来对”，每次筛选后顺手 print 一下 .shape 和前两行，比事后查半天快得多。 
