可测试性差的函数应解耦数据获取与计算逻辑，显式传入外部依赖；严格声明数值类型与精度；避免滥用np.vectorize；必须覆盖inf、nan等边界值测试。
函数必须接收原始输入，别在内部读文件或调用全局状态
可测试性差的典型表现是：一跑单元测试就报 FileNotFoundError，或者结果随系统时间/环境变量变化。根本原因是函数把“怎么获取数据”和“怎么计算”混在一起。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 把文件路径、配置值、当前时间等外部依赖，全部作为参数传入，而不是在函数里写
open("data.csv")或datetime.now() - 如果原有逻辑已耦合，先抽一个纯计算函数（比如叫
compute_velocity），再另写一个包装函数负责读取和转换 - 测试时直接喂
[1.0, 2.5, 3.7]这种明确列表，而不是 mock 文件系统——mock 增加维护成本，且容易掩盖边界处理缺陷
避免隐式类型转换，显式声明数值类型和精度预期
python 的动态类型让 int 和 Float 在计算中悄悄混合，导致测试通过但生产环境因浮点误差失败，比如 0.1 + 0.2 != 0.3 在断言中直接翻车。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 输入参数用
typing.union[float, int]或更严格的float，别留Any；输出也明确返回类型，避免返回np.float64却期望float - 比较浮点结果时，永远用
math.isclose(a, b, abs_tol=1e-9)，不用== - 涉及金融或物理量计算，优先考虑
decimal.Decimal，并在函数文档里写清：“本函数不接受numpy.ndArray，请先用.tolist()转换”
NumPy 函数要区分 vectorize 和原生 ufunc，别把广播当万能解
看到数组就无脑上 np.vectorize，结果测试用小数组快，上线后大数据量反而比纯 Python 循环还慢——这是常见性能陷阱。
实操建议：
立即学习“Python免费学习笔记（深入）”；
-
np.vectorize只是语法糖，没实际向量化，它本质仍是 Python 循环；真要提速，得用原生 ufunc（如np.sin、np.add）或numba.jit - 测试时别只喂
np.array([1, 2, 3])，加一组长度为 10000 的随机数组，用timeit看耗时是否线性增长 - 如果必须自定义计算逻辑，优先写成支持广播的纯 NumPy 表达式，例如用
a ** 2 + 2 * a * b + b ** 2替代np.vectorize(Lambda x, y: (x + y) ** 2)
测试用例必须覆盖 inf、nan、负零、极值边界
数值计算函数最容易在 CI 里沉默失效：测试数据全是正数小数，上线后用户传进 np.inf 或 -0.0，函数直接返回意外结果，而断言没覆盖这些情况。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 每个数值函数至少补 4 类测试输入：
float("inf")、float("nan")、-0.0、sys.float_info.max - 别信“这不会有人传”，现实里 CSV 导入常把空格转成
nan，C++ 库回调可能带-0.0，科学仪器数据常含inf - 用
np.testing.assert_array_equal或assert np.all(np.isfinite(result))显式检查输出合法性，而不是只比对几个样本值
数值计算的可测试性不是加一堆 mock 和装饰器，而是把“数据从哪来”“算到什么精度”“异常怎么流”这三件事，在函数签名和测试用例里钉死。越早拒绝模糊输入，后期 debug 越少对着日志猜半夜。