必须确认sysconfig.get_platform()输出为linux-aarch64等ARM标识，而非仅依赖uname -m；需安装匹配架构的python3-dev、正确工具链，并用sys.platform和platform.machine()条件配置setup.py，避免硬编码。
直接在 ARM 设备上编译 Python C 扩展模块，只要环境配齐就能成功；但多数失败不是因为“不能编译”，而是平台标识错、工具链不匹配、或依赖库路径没对上。
确认当前 Python 的 platform 标识是否真实反映 ARM 环境
Python C 扩展的二进制兼容性完全依赖 sysconfig.get_platform() 的输出，而不是你看到的 uname -m 或系统名称。比如树莓派 5（ARM64）上运行的 Python，如果 sysconfig.get_platform() 返回的是 linux-x86_64，那说明你用的是 x86_64 构建的 Python（可能是通过 QEMU 模拟），此时编译出的 .so 必然段错误或 Symbol not found。
- 运行
python -c "import sysconfig; print(sysconfig.get_platform())"—— 这个字符串会出现在 wheel 文件名里，也决定 build_ext 调用哪个编译器 - 正确值应类似
linux-aarch64（ARM64）、linux-armv7l（32 位 ARM） - 若结果异常，别硬改 setup.py，先查 Python 是怎么装的：是 apt 安装的原生包？还是从源码交叉编译来的？或是通过 conda/miniforge 安装？
确保系统已安装对应架构的 Python 开发头文件和交叉工具链
在 ARM Linux（如 Raspberry Pi OS、Debian ARM64）上，python3-dev 包必须与当前 Python 二进制严格匹配架构。只装 gcc 不够，缺 Python.h 或 pyconfig.h 会导致 fatal error: Python.h: No such file or directory。
- Debian/Ubuntu ARM：运行
sudo apt install python3-dev（注意不是python-dev） - Alpine ARM：用
apk add python3-dev gcc musl-dev，否则 pip install 含 C 扩展的包（如cryptography）会因找不到gcc直接失败 - 若你在 x86 主机上交叉编译 ARM 的扩展，必须用
arm-linux-gnueabihf-gcc或aarch64-linux-gnu-gcc，且 Python 解释器也得是 ARM 版本（例如python3.11-aarch64），不能混用 x86 的python3
setup.py 中避免硬编码平台相关参数
Extension 构造函数本身不识别平台，真正起作用的是 build_ext 命令如何调用编译器。硬写 extra_compile_args=["-march=armv8-a"] 在非 ARM 平台会直接编译失败，也不利于 CI 复用。
立即学习“Python免费学习笔记（深入）”；
- 用
sys.platform和platform.machine()做条件判断，例如：if sys.platform == "linux" and platform.machine() in ("aarch64", "armv7l"): - Linux ARM 上慎用
-march=native—— 它会把 CPU 特性（如 SVE）编进指令，导致在老款 ARM 芯片上跑出Illegal instruction - 链接数学库时写
libraries=["m"]即可，不用写绝对路径；但若提示undefined reference to `pow'，说明library_dirs没包含/usr/lib或/lib
pip install 时跳过预编译 wheel 或强制源码构建
很多包（如 numpy、pandas）在 PyPI 上有 aarch64 wheel，但版本滞后或缺失。pip 默认优先下载 wheel，若找不到就 fallback 到源码构建——前提是环境满足。
- 强制从源码构建：
pip install --no-binary=:all: package_name - 查看可用 wheel：
pip debug --verbose看platform_tag是否为manylinux2014_aarch64或manylinux_2_28_aarch64 - 若 wheel 下载后报
ERROR: package_name-1.2.3-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl is not a supported wheel on this platform，说明 wheel 标签和本地 platform 不符，不是 bug，是预期行为
最常被忽略的一点：编译后的 .so 文件虽然能 import，但若它动态链接了某个 ARM 特定版本的系统库（如 libssl.so.3），而目标设备上只有 libssl.so.1.1，运行时仍会崩。这时候得用 readelf -d your_module.cpython-*.so | grep NEEDED 检查实际依赖，再决定是静态链接还是补全系统库。
