Python稀疏矩阵处理及四种格式对比

选csc_matrix还是csr_matrix取决于操作方向：列切片用csc_matrix，行切片用csr_matrix；coo_matrix仅适用于构造阶段，需转为csr/csc才能运算；lil_matrix仅适合动态构建，完成后必须转换；拼接矩阵前须统一格式并校验形状。

稀疏矩阵该选 csc_matrix 还是 csr_matrix？

取决于你主要做「列切片」还是「行切片」——csc_matrix（Compressed Sparse Column）对列操作快，csr_matrix（Compressed Sparse Row）对行操作快。底层是用三个数组存非零值、行索引、列指针（或反之），结构差异直接决定访问效率。

常见错误现象：mat[:, 5] 在 csr_matrix 上会触发全矩阵转置再切片，慢得离谱；反过来，mat[3, :] 在 csc_matrix 上也一样。

• 做特征提取、按列标准化（比如每列减均值）→ 优先用 csc_matrix
• 做样本采样、按行计算 L2 范数、批量预测 → 优先用 csr_matrix
• 从 scipy.sparse.load_npz() 加载后默认是 csr，别直接拿去列操作
• 转换开销不可忽略：mat.tocsc() 或 mat.tocsr() 是 O(nnz) 时间，不是常数

coo_matrix 为什么不能直接做乘法？

coo_matrix 是最原始的三元组格式（行索引、列索引、值），不支持算术运算和切片，因为没建索引结构——它连「某行有哪些非零元」都得遍历找。

使用场景：只适合构造阶段。比如从文件逐行读取 (i, j, val)，append 到三个列表里，最后一次性转成 coo_matrix，再立刻转成 csr 或 csc。

• 误用 coo_matrix 做 @ 矩阵乘 → 报错 TypeError: unsupported operand type(s) for @: 'coo_matrix' and 'coo_matrix'
• coo_matrix 允许重复 (i,j)，但转成 csr/csc 时会自动求和，这是隐式行为，容易漏掉数据异常
• 构造完必须转：用 .tocsr() 或 .tocsc()，别留着 coo 做后续计算

lil_matrix 适合动态插入，但千万别用它存最终结果

lil_matrix（List of Lists）内部用 Python 列表存每行的列索引和值，支持 mat[i, j] = x 这种随机写入，但内存占用高、访问慢、不支持广播运算。

性能影响明显：10 万行 × 10 万列的稀疏矩阵，用 lil 存可能吃掉 2–3 倍内存，且 mat.sum(axis=1) 比 csr 慢一个数量级。

• 只在「边生成边填」场景用：比如迭代算法中逐行构造矩阵
• 填完立刻转：mat.tocsr() 是标准收尾动作，不是可选项
• 别用 lil_matrix 做 np.dot 或传给 sklearn 模型——很多模型内部会检查格式，遇到 lil 直接报 ValueError: Expected CSR or CSC matrix

用 scipy.sparse.bmat 拼接矩阵时维度对不上怎么办？

bmat 要求子块在逻辑上能排成矩形，比如 [[A, B], [C, D]] 中，A.shape[0] 必须等于 C.shape[0]，A.shape[1] 等于 B.shape[1]，否则报 ValueError: blocks must be 2-D 或更模糊的 inconsistent shapes。

容易踩的坑是混用不同格式：比如 A 是 csr，B 是 coo，bmat 不会自动统一，可能在拼接中途因格式不兼容崩掉。

• 拼之前先统一格式：A.tocsr(), B.tocsr(), C.tocsr(), D.tocsr()
• 手动校验形状：assert A.shape[0] == C.shape[0] 和 assert A.shape[1] == B.shape[1]，比看报错信息快得多
• 如果只是水平拼（[A, B]），用 scipy.sparse.hstack([A, B]) 更稳；垂直拼用 vstack，它们对形状要求更明确，报错也更直白

稀疏格式转换不是“无感”的，每次 .tocsr() 都在重排数据；而不同格式对同一操作的时间差可以到百倍。真正卡住你的往往不是算法，而是矩阵刚加载完就用错了格式。