📚 课程目录第2章环境搭建

环境搭建：你需要打好的第一根桩

说实话，我见过太多 DLP 联调的同事，第一个坑就栽在环境上。

SDK 本身再稳，操作系统不合规、编译器版本不对、Python 解释器不匹配——光这些就够你排查半天。而我早期在 Linux 上调加密模块时就遇到过这样的坑：明明代码逻辑一点问题都没有，就是加载动态库报段错误，最后发现是系统自带的 gcc 版本太老，结构体对齐方式不一致导致的。

好，咱们把这根桩打牢。

操作系统的选择与依赖

DLP 加密 SDK 的核心是 C/C++ 动态库，所以它跟底层的系统调用接口绑定得很紧。我个人习惯先在 Ubuntu 20.04 （LTS） 或 CentOS 7.9 上验证，这两个发行版覆盖了主流的 glibc 和 libstdc++ 版本。

操作系统	推荐版本	glibc 版本	备注
Ubuntu	20.04 LTS / 22.04 LTS	2.31 / 2.35	包管理完善，我最推荐
CentOS	7.9 / 8.4	2.17 / 2.28	生产环境常见，注意 glibc 版本较老
Windows	10 （20H2+） / Server 2019+	—	特别注意 Visual C++ 可再发行组件
macOS	12+ （Monterey）	—	仅用于开发调试，不支持生产部署

曾经踩过的坑： 我记得有一次在 CentOS 7 上部署，SDK 调用远程密钥协商时一直报证书验证错误，查了一下午，结果是系统自带的 OpenSSL 版本是 1.0.2，不支持 TLS 1.3。最后升级到 1.1.1 才搞定。所以，检查依赖时别只看 glibc，openssl version 和 ldd --version 两个命令一定要跑一遍。

Python 版本：精确到次版本号

这个知识点，我建议你记牢。很多人觉得「Python 3 都行」，但在 DLP SDK 的 Python 封装层里，次版本差异能造成接口二进制不兼容。你想想看，Python 3.7 的 PyLong_AsLongLong 在 3.10 里行为就变了——直接导致指针参数解析错位，加密结果全是乱码。

我的建议：

开发环境：Python 3.8.10 或 3.10.12（这两个版本经过了 SDK 团队的全面回归测试）
推荐使用 pyenv 管理多版本，我的工作站上就同时装了 3.8、3.10、3.11，切换起来很方便
创建虚拟环境：python3.10 -m venv dlp_env
验证命令：python --version && python -c "import sys; print（sys.maxsize）"——确认是 64 位，32 位 Python 会直接导致内存布局异常

  一句话避坑： 如果你在 Windows 上用的是 Anaconda，记得用 conda install python=3.10.12 锁定次版本，别让 Anaconda 自动升级到 3.11。我曾经在 CI 流程里因为 conda 自动更新了 Python，导致加密函数的参数校验全部失败，排查了整整两天。

C/C++ 编译工具链：每个平台都有脾气

SDK 核心是 C/C++ 写的，调试时免不了要自己编译测试桩或者打 patch。工具链配不对，你连 make 都跑不动。

Linux 平台

我习惯用 gcc 9.4 起跳。Ubuntu 20.04 默认就是这个版本，支持完整的 C++17，SDK 里用到的 std::variant 和 std::optional 都兼容。

# Ubuntu/Debian 系
sudo apt update
sudo apt install build-essential cmake g++-9

# CentOS/RHEL 系
sudo yum install epel-release
sudo yum install centos-release-scl
sudo yum install devtoolset-9-gcc devtoolset-9-gcc-c++
scl enable devtoolset-9 bash

Windows 平台

用 MSVC 的话，确保安装 Visual Studio 2019 （16.11+）或 2022。安装时勾选「使用 C++ 的桌面开发」工作负载。

注意：DLP SDK 的 Windows 版本默认是用 MT（静态链接运行时）编译的，你编译自己的测试程序时也要保持一致的运行时库设置，否则在 CRT 堆管理上会有冲突，运行时会莫名其妙地内存访问违例。

# 我常用的 CMakePresets.json 片段
{
  "version": 3,
  "configurePresets": [
    {
      "name": "windows-debug",
      "generator": "Visual Studio 16 2019",
      "binaryDir": "${sourceDir}/build/x64-Debug",
      "cacheVariables": {
        "CMAKE_MSVC_RUNTIME_LIBRARY": "MultiThreadedDebug"
      }
    }
  ]
}

小技巧： 如果你在 Windows 上调试时遇到 LNK2038 这类运行时库不匹配的错误，检查一下 CMake 里的 CMAKE_MSVC_RUNTIME_LIBRARY 是否与 SDK 保持一致。SDK 头文件里一般会贴出它的编译选项，照抄就行。

macOS 平台

直接用 Xcode Command Line Tools 就行。我很少在 macOS 上做完整集成测试，但用它做快速原型验证很方便。

xcode-select --install
# 确认 clang 版本
clang --version  # 需要 >= 13.0

整体环境链路一览

下面这张 SVG 图总结了从操作系统到 SDK 调用之间的依赖关系，也是我每次搭建新环境时对照的检查清单。配好这些环节，后面的调试就顺了。

  环境验证 Checklist：

  ✅ 操作系统版本符合 glibc/libstdc++ 约束

  ✅ OpenSSL >= 1.1.1（生产环境建议 3.0.x）

  ✅ Python 次版本锁定在 3.8.10/3.10.12

  ✅ 编译器版本 ≥ gcc 9.4 / MSVC 2019 / clang 13

  ✅ 运行时库设置（Windows MT/MD）与 SDK 一致

  ✅ ldd libdlp.so 或 otool -L libdlp.dylib 所有依赖存在

你按照这个链路从上到下配好，基础环境就稳了。

其实多数联调问题都不是 SDK 本身的 bug，而是环境不一致导致的——你想想看，两个机器 glibc 差一个次版本，指针大小可能都一样，但堆的碎片整理行为不同，加密性能就差出 30%。这些细节我后几章还会反复提到，但今天先把地基打牢。