Wheel包本质是符合PEP 427的ZIP归档，含METADATA、WHEEL、RECORD等UTF-8文本文件及编译模块（如.so/.pyd），C++只需用libzip等解压读取，无需解析协议或绑定Python运行时。
Wheel包本质是ZIP，C++只需解压而非“解析”
Wheel不是专有二进制格式，而是符合PEP 427的普通ZIP归档，内含METADATA、WHEEL、RECORD等文本文件和编译好的扩展模块（如.so或.pyd）。C++不需实现Wheel协议，只需用ZIP库提取并读取关键文件。
常见错误是试图用Python C API或硬解析dist-info目录结构——其实只要能打开ZIP，就能拿到所有元数据。
- 推荐用
minizip（libzip 的轻量替代）或libzip，避免自己写ZIP解析逻辑 - 注意Wheel文件名带平台标签（如
requests-2.31.0-py3-none-any.whl），C++不负责校验兼容性，但可从文件名提取python_tag、abi_tag、platform_tag - Windows下需处理路径分隔符：ZIP内部路径用
/，但libzip默认返回正确路径；若手动解析ZIP中央目录，别用\做字符串分割
读取WHEEL和METADATA文件需要正确编码
WHEEL 和 dist-info/METADATA 是UTF-8文本，但部分旧Wheel可能含非ASCII字段（如作者名），且METADATA使用RFC 5322风格头字段（冒号后空格可选，换行可折行）。C++不能靠简单std::getline暴力切分。
- 用
libzip打开后，调用zip_fopen+zip_fread读取完整内容，再交给std::string持有 - 解析
METADATA时，按^([A-Za-z0-9-]+):[[:space:]]*(.*)$逐行匹配（注意折行：下一行以WS开头即为前一行续写） - 不要假设字段顺序——
Wheel-Version可能在Generator之后，Requires-Dist可能出现多次
验证RECORD签名需额外处理base64和hash算法
dist-info/RECORD 是CSV格式（逗号分隔，路径+hash+size），每行形如 foo.py,sha256=abc123...,1234。C++需校验文件完整性，但标准库无内置base64解码和SHA256。
立即学习“Python免费学习笔记（深入）”；
- 用
openssl（EVP_DigestInit系列）或libsodium计算文件哈希，别手写SHA256 - base64解码必须严格：PEP 427要求使用标准base64（非URL安全），且末尾
=补位不可省略；boost::beast::detail::base64_decode或 OpenSSL 的EVP_DecodeBlock更可靠 - 注意
RECORD本身也需被校验——它的哈希记录在自身最后一行，循环校验时先跳过最后一行计算摘要，再比对
跨平台加载.so/.pyd需绕过Python运行时绑定
C++若想直接调用Wheel里的C扩展（如numpy.libs/libopenblas64_.so），不能依赖PyImport_ImportModule——那属于Python解释器行为。你得用系统动态加载API，但面临符号可见性、依赖链、ABI不匹配三重坑。
- Linux/macOS用
dlopen/dlsym，但需确保RPATH或LD_LIBRARY_PATH包含numpy.libs等附属目录（Wheel常把依赖放在同级.libs子目录） - Windows用
LoadLibraryEx+GetProcAddress，注意.pyd本质是DLL，但导出符号通常是PyInit_modulename而非业务函数 - 绝大多数情况下，你不该这么做——Wheel的C扩展是为CPython ABI设计的，直接dlopen易崩溃；真要复用，应通过Python C API启动嵌入式解释器，再用
PyRun_SimpleString导入模块
真正棘手的从来不是解压或读文本，而是当Wheel里混着manylinux2014_x86_64的.so和你的glibc版本不兼容时，dlopen静默失败却只报Cannot allocate memory——这种问题不会出现在文档里，只藏在strace输出里。
