Cython循环未提速反更慢，主因是未切断Python解释器开销：未用cdef声明循环变量和长度、循环内调用len()/range()/Python列表、未用typed memoryview声明NumPy数组、编译未加-O3/-march=native优化参数。
为什么你的Cython循环没提速，反而更慢？
直接用 cdef 声明变量但没关掉 Python 解释器开销，循环体里还在调用 len()、range() 或访问 Python 列表，这是最常见原因。Cython 默认仍走 Python 对象路径，只有显式切断与解释器的绑定，才能释放 C 级性能。
- 必须用
cdef声明所有循环变量、索引、数组长度（不能用len(my_list)） - 避免在循环内调用任何 Python 函数——包括
print()、abs()（改用fabs()）、math.sqrt()（改用sqrt()并from libc.math cimport sqrt） - 输入数据尽量用 NumPy 数组，并用
np.ndarray[double, ndim=1]这类类型声明，而非普通list
如何正确声明 NumPy 数组并启用内存视图加速？
用 np.array(..., dtype=np.float64) 创建数组只是第一步；关键是在 Cython 文件中用内存视图（memoryview）或 typed memoryview 声明，让编译器跳过边界检查和对象封装。
- 推荐写法：
cdef double[:] arr_view = input_array（通用 memoryview），或更严格的cdef double[::1] arr_view = input_array（保证连续内存） - 不要写
cdef np.ndarray[double, ndim=1] arr = input_array—— 老式声明仍带部分 Python 开销，且在新版本 NumPy + Cython 中已不推荐 - 如果确定数组是 C 连续且只读，加
const：cdef const double[::1] arr_view = input_array，可进一步提示编译器优化
编译时忘记加 -O3 和 -march=native 会损失 30%+ 性能
Cython 生成的是 C 代码，最终性能取决于 C 编译器优化级别。默认 setup.py 调用 gcc 时几乎不优化，相当于“裸奔”。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 在
setup.py的Extension中加入：extra_compile_args=['-O3', '-march=native'] - Linux/macOS 下建议再加
-ffast-math（注意：它会让 NaN/Inf 行为不严格符合 IEEE，但科学计算通常可接受） - Windows 用户用 MSVC 需换参数：
/O2 /arch:AVX2（需确认 CPU 支持） - 验证是否生效：编译后查看生成的
.c文件，搜索__PYX_ERR—— 如果大量存在，说明仍有 Python 错误处理未剥离，需回查类型声明
prange 并行循环报 RuntimeError: Indexing expected for parallel section 怎么办？
用 prange 前必须满足两个硬性条件：索引变量必须是 cdef int，且循环必须是纯整数步进（不能是 for i in prange(len(arr))，因为 len() 是 Python 调用）。
立即学习“Python免费学习笔记（深入）”；
- 正确写法：
for i in prange(arr_view.shape[0], schedule='dynamic', nogil=True): -
nogil=True是必须的，否则无法真正并行；同时确保循环体内不出现任何 Python API 调用（如print、列表追加、字典操作） - 若需写入结果数组，目标数组也必须是 typed memoryview 且声明为
cdef double[::1]，否则 GIL 会自动重入 - 小数组（prange 反而更慢——线程启动开销压倒计算收益
cdef 就完事”，核心在于主动切断 Python 运行时依赖。最容易被忽略的是：即使所有变量都 cdef 了，只要循环里有一次 arr[i] 访问的是普通 Python list，整个循环就退化回解释执行。务必从数据源头开始控制类型。 
