小白视角：一个 Python 包从源码到 wheel 的“流水线”
把它想成你在装一个“带原生零件”的包（里面有 C/C++/CUDA）：
A. 你pip install xxx时，pip 会先找有没有现成 wheel
有 wheel：
直接下载一个已经编译好的.whl（相当于“成品件”）→ 解压安装 → 完事没 wheel：
只能下载源码包（sdist，通常是.tar.gz）→在你电脑上现场编译→ 再装
B. “现场编译”具体干嘛（你平时看不到，但它真在干）
找编译器：gcc/g++（C/C++）
如果有 GPU 部分：找 CUDA Toolkit（
nvcc）读取你当前环境：Python 版本、PyTorch 版本、CUDA 版本、平台（linux/windows）、架构等
把 C++/CUDA 代码编译成
.so（Linux）或.pyd/.dll（Windows）把这些二进制文件打包成 wheel，安装到你的 site-packages
wheel 本质：别人已经把步骤 1~4 做完了，给你步骤 5 的结果。
1.gcc / g++
这是啥？
C / C++ 的编译器
为啥你会碰到它？
很多深度学习库（PyTorch 扩展、CUDA 算子、各种 xxx.so）底层都是 C++ 写的，安装时需要现场编译。
痛点：
版本不对 → 编译直接炸
系统 gcc 太老 / 太新 → ABI 不兼容
Conda 里的 gcc 和系统 gcc 打架
没 wheel：你就得自己操心这些
有 wheel：别人已经编译好了，你不用管
2.CUDA Toolkit 版本
这是啥？
NVIDIA 的 GPU 编程工具链（nvcc、CUDA runtime 等）
为啥要匹配？
你显卡支持的 CUDA 版本是有限的
PyTorch 是按 CUDA 版本编译的
CUDA ≠ 驱动（很多人第一次就死在这）
经典翻车现场：
系统 CUDA 11.8
装了个 PyTorch + CUDA 12.1 的 wheel
结果：
libcudart.so not found
wheel = 已经帮你锁死「能跑的 CUDA 组合」
3. PyTorch ABI
这是啥？
二进制接口规范（说白了：C++ 世界的“暗号”）
为啥会出问题？
PyTorch 用 C++ 写
你装的扩展（如 torch-scatter、xformers）也用 C++
只要 ABI 不一致，就会：
undefined symbol
你会怀疑人生，但其实不是你代码的问题。
wheel：
和 PyTorch 用同一套 ABI编出来的
插上就能用
4.GLIBCXX / cxx11abi
这是啥？
C++ 标准库版本 & 编译规范问题
Linux 用户专属折磨
典型报错：
GLIBCXX_3.4.26 not found
为什么这么阴间？
系统自带的 libstdc++ 太老
编译用的新 gcc
运行时却加载了旧库
wheel 通常：
用老系统编译（向下兼容）
避开你本地系统的坑
5. “等上十几分钟甚至失败”
这是最终 Boss
前面四个东西：
任意一个不匹配 → 编译失败
有时跑 20 分钟才告诉你失败
日志长到你根本不想看
一句话总结（重点）
Wheel = 预编译好的“成品二进制包”
它帮你解决了：
| 问题 | 没 wheel | 有 wheel |
|---|---|---|
| gcc | 自己装 | 不用 |
| CUDA | 自己对 | 已对好 |
| ABI | 靠运气 | 已锁死 |
| GLIBCXX | 地狱 | 跳过 |
| 时间 | 30 分钟 | 30 秒 |
