NumPy 的 np.array 不是万能列表，业务代码中应避免用它接收用户输入或存字典键值；仅在明确需向量化运算时初始化，并显式指定 dtype。
NumPy 的 np.array 别当「万能列表」用
业务代码里直接拿 np.array 接收用户输入、拼接配置项、存字典键值，十有八九会翻车。它不是 Python 列表的加速版，而是为同构数值计算设计的容器。
常见错误现象：TypeError: unhashable type: 'numpy.ndarray'（想把数组当字典 key），或 ValueError: setting an array element with a sequence（往 float 类型数组里塞字符串）。
- 业务场景下优先用原生
list或dict：增删改查频繁、数据类型混杂、生命周期短 -
np.array只在明确需要向量化运算时才初始化：比如批量价格重算、时间序列差分、矩阵乘法 - 初始化时显式指定
dtype，别依赖自动推断——np.array(['1', '2', '3'])得到的是object类型数组，性能和行为都反直觉
Pandas 的 apply 在业务逻辑里容易成性能黑洞
写报表逻辑时习惯性对 DataFrame 每行用 apply 调函数，看起来干净，但实际是用 Python 循环套 Python 函数，完全没发挥 Pandas 底层优势。
典型表现：处理 10 万行数据耗时从 200ms 拉长到 8 秒以上；内存占用翻倍；无法并行或 JIT 加速。
立即学习“Python免费学习笔记（深入）”；
- 优先用向量化方法：
df['price'] * df['tax_rate']，而不是df.apply(lambda x: x['price'] * x['tax_rate'], axis=1) - 真要复杂逻辑，先拆出纯 NumPy 可操作的列，再用
np.where、np.select或布尔索引替代嵌套 if-else - 万不得已用
apply，记得加result_type='expand'或raw=True避免 Series 封装开销
SciPy 的 optimize.minimize 不适合做实时定价策略
业务系统里有人把定价模型包装成目标函数，每次请求都调一次 scipy.optimize.minimize，结果接口 P99 延迟飙升到 2 秒+，还经常收敛失败。
根本原因：科学计算优化器默认追求高精度解，启动开销大、迭代不可控、不保证实时性；而业务定价要的是“够快 + 稳定 + 可解释”。
- 离线训练阶段可用
minimize找初始参数，上线后换成解析解或查表 + 插值 - 如果必须在线优化，限制
options={'maxiter': 10, 'disp': False}，并预设 fallback 值防止不收敛 - 注意
method参数：业务场景下'L-BFGS-B'比默认的'BFGS'更稳，支持边界约束也更贴近真实定价区间
业务代码里混用 decimal.Decimal 和 np.float64 会丢精度
财务计算用 Decimal，科学计算用 float64，这没问题。但一旦两者在同一个表达式里混合运算，Python 会静默转成 float，Decimal('0.1') + np.float64(0.2) 结果是 0.30000000000000004。
这种 bug 很难测出来，只在特定金额组合下暴露，线上可能几周才触发一次对账差异。
- 定义清楚数据流边界：输入进业务模块前统一转
Decimal，输出前再转回 float（如有必要） - 避免在 Pandas 中用
Decimal：Series dtype 不支持，会退化成 object，后续所有运算变慢且不可预测 - 用
np.isclose替代==做浮点比较，但注意它不适用于Decimal——得用quantize或to_eng_string后比字符串
事情说清了就结束。边界不是画条线完事，是每次写 import numpy 时多问一句：这里真的需要它吗？
