应默认使用np.matmul或@而非np.dot：前者语义唯一、契约清晰、报错直接，二维时校验更严格，高维时按batch矩阵乘输出预期形状(如(2,3,5))，不隐式广播或类型提升；np.dot行为模糊，高维易产出意外形状(如(2,3,2,5))或静默错误。
np.dot，而应默认用 np.matmul 或 @。
np.dot 行为模糊、广播隐晦、类型提升不可控，容易在高维场景下产出意外形状或静默错误；np.matmul 才是专为矩阵乘法设计的现代接口，契约清晰、报错直接、语义唯一。
np.matmul 对二维数组更可靠
虽然 np.dot(a, b) 和 np.matmul(a, b) 在二维时输出一致，但它们的校验逻辑不同：
-
np.matmul明确要求a.shape[1] == b.shape[0]，错误信息直指“core dimension mismatch” -
np.dot的报错可能是模糊的operands could not be broadcast together，尤其当输入含冗余维度时（如 shape=(1, m, n)） - 若你写的是模型前向传播代码，
@能一眼看出是矩阵乘，dot则可能被误读为“点积”或“加权求和”
np.dot 在三维及以上会悄悄改变输出形状
这是最常踩坑的地方。例如：
- 当
a.shape = (2, 3, 4)、b.shape = (2, 4, 5)时：np.matmul(a, b)→ 输出(2, 3, 5)（batch 矩阵乘）np.dot(a, b)→ 输出(2, 3, 2, 5)（对最后两轴乘，其余维度广播，中间多了一维） - 若
b.shape = (4, 5)（无 batch 维），np.matmul直接报错，np.dot却尝试广播，结果可能完全偏离预期 - 这种差异在 Transformer 的 attention 权重计算或 CNN 的 channel-wise reshape 场景中极易引发 silent bug
np.matmul 不做隐式 dtype 提升，错误更早暴露
当你混合使用整型和浮点型数组时：
-
np.dot(np.array([1, 2], dtype=np.int32), np.array([3.0, 4.0], dtype=np.float64))→ 返回float64标量，悄无声息 -
np.matmul在同样输入下直接抛TypeError: No loop matching the specified signature and casting was found - 这种“拒绝妥协”的设计能帮你提前发现 dtype 混用问题，避免在大规模训练中因精度丢失导致 loss nan
np.dot 的场景极少——仅限明确依赖其高维广播语义的信号处理（如某些 cross-correlation 实现）或旧代码兼容。日常写法里，只要你想做矩阵乘，就该用 @ 或 np.matmul。它不省事，但省 debug 时间。 
