简介：面向 Windows 平台下使用 C++ 处理 PDF 的开发者，这套 PoDoFo 0.9.5 的 VS2013 x86 库提供了可直接接入工程的编译产物，适合需要在 32 位 Visual Studio 2013 项目中读取、解析与生成 PDF 的技术人员。压缩包共 113 个文件，以 107 个 .h 头文件为主体，涵盖文档、页面、字段、字体、加密、绘制等模块的接口声明；另含 2 个 dll 动态库、2 个 lib 导入库和 2 个 pdb 调试符号，整体约 6.74MB。已有 318 人学习下载。其价值在于头文件与二进制库配套齐全，可省去从源码编译 PoDoFo 及处理依赖链接的重复劳动，pdb 文件也便于在调试中定位库内问题；对需要快速把 PDF 读写能力集成进既有 MFC 或 Win32 工程的团队较为实用。
1. 为什么今天还要在 vs2013 里编一份 x86 的 podofo-0.9.5 库
手上有个跑了多年的 Windows 桌面工具，工具链锁死在 v120，进程是 32 位的，谁也没权限动它。现在要给它加 PDF 能力：把几十份单据合成一份、给首页盖个水印、读一下既有 PDF 的页数。商业 SDK 授权谈不下来，换编译器比写代码风险大，podofo-0.9.5 就这么进了名单——纯 C++、源码可控、能直接摸内容流。
真正麻烦的地方不在 PoDoFo 本身，在于 0.9.5 是 CMake 驱动的，默认假设你有一副完整的 C++11 工具链，而 vs2013 的 C++11 支持是半截的，x86 平台更没人替你验过。这篇按我实际走通的顺序写：先钉死工具链约束，再把依赖编成同位数同运行时库，然后才动本体，最后把踩过的坑摊开。你要是也困在「老工具链 + 32 位 + 必须自己编库」，路径基本能照搬。
2. 先把工具链对齐：CMake 生成 VS2013 Win32 工程的三条硬约束
2.1 为什么不直接找仓库里现成的 sln
拿到源码包的人第一反应都是翻目录找*.sln，找到就双击。多数时候确实能找到，但它们通常对应作者手边的工具集，用 VS2013 打开会弹重定向向导，重定向完编译，报的错往往比从头走 CMake 还多。更关键的是配置不全：有的工程只留了 x64，有的 Debug/Release 四套配置里只维护一套，x86 的 Win32 配置压根不存在。
走 CMake 的理由不是它更先进，而是它是唯一能保证「生成器 + 平台 + 运行时库」三件事同时被你控制的路子。你要出静态库、要 Win32、要 /MT，这三个决定如果不从 CMake 这一层下进去，后面在 IDE 里一个个改工程属性，改漏一个子项目，链接期就还你一个 LNK2038。
还有一条容易被忽略：CMake 本身的版本。PoDoFo 0.9.5 那个年代的CMakeLists.txt里写的是很低的cmake_minimum_required，用最新版 CMake 配它，会直接撞上「Compatibility with CMake < 3.5 has been removed」这类硬报错；反过来用太老的 CMake（2.8 系列），又不认-A参数。实操上选 3.x 的中段版本最省事，能生成 VS2013 工程、又还没删掉老版本兼容逻辑。
2.2 三条约束：生成器名、平台参数、运行时库
第一条是生成器名。VS2013 在 CMake 里的生成器名是Visual Studio 12 2013，64 位版本是Visual Studio 12 2013 Win64——注意这是两个独立的生成器字符串，不是靠参数区分的。所以在 VS2013 这个年代，你只要不带Win64，生成出来的默认就是 Win32。
第二条是平台参数。CMake 3.1 之后引入了-A，可以写成-A Win32显式指定。加上它没坏处，能防止你哪天把命令行复制到另一个 CMake 版本上时行为漂移。但如果你的 CMake 是老版本，-A会直接被当成未知参数，这时候只能靠生成器名本身保证位数。
第三条是运行时库，也是最容易翻车的一条。VS 工程默认用/MD（Release）和/MDd（Debug），也就是动态链接 CRT。如果你的宿主程序是/MT静态链接 CRT，那你编出来的 podofo.lib 扔进去就是一堆 LNK2038。这件事必须在 CMake 配置阶段就决定，不能等到 IDE 里改。
# 在 32 位 VS2013 开发者命令提示符下执行 # 目录约定：源码 D:/work/podofo-0.9.5，依赖 D:/work/deps，构建 D:/work/build/v120-x86 cmake ^ -G "Visual Studio 12 2013" ^ -A Win32 ^ -DPODOFO_BUILD_LIB_ONLY=ON ^ -DPODOFO_BUILD_SHARED=OFF ^ -DPODOFO_BUILD_STATIC=ON ^ -DCMAKE_DEBUG_POSTFIX=d ^ -DCMAKE_C_FLAGS_RELEASE="/MD /O2 /DNDEBUG" ^ -DCMAKE_CXX_FLAGS_RELEASE="/MD /O2 /DNDEBUG" ^ -DCMAKE_C_FLAGS_DEBUG="/MDd /Od /D_DEBUG" ^ -DCMAKE_CXX_FLAGS_DEBUG="/MDd /Od /D_DEBUG" ^ -DCMAKE_INCLUDE_PATH="D:/work/deps/zlib/include;D:/work/deps/jpeg/include;D:/work/deps/freetype/include" ^ -DCMAKE_LIBRARY_PATH="D:/work/deps/zlib/lib;D:/work/deps/jpeg/lib;D:/work/deps/freetype/lib" ^ ../podofo-0.9.5这段命令里，-G和-A决定了工程长什么样，后面四个CMAKE_*_FLAGS_*决定 CRT 链接方式。我用/MD是因为宿主程序本来就是动态 CRT，改它成本更高；你要是/MT阵营，把这四处和三个依赖库的构建参数一起换成/MT、/MTd，少换一个都会在链接期被揪出来。CMAKE_DEBUG_POSTFIX=d是为了让 Debug 和 Release 的库能放在同一个输出目录里不打架，后面会用到。CMAKE_INCLUDE_PATH和CMAKE_LIBRARY_PATH是给find_package兜底的搜索路径，不是万能钥匙——它只影响查找，不影响查找失败时的报错内容。
2.3 生成完之后，先查四个东西再动手编
工程生成成功不代表配置正确，一定要先回头看缓存。用cmake -LA -N .把缓存变量全列出来，或者直接打开 CMake GUI 搜关键字。
第一个要查的是平台。打开生成的.sln，看解决方案配置下拉里有没有Win32，如果只有x64，说明生成器选错了，删掉CMakeCache.txt重来，别在 IDE 里手动加配置。
第二个查ZLIB_INCLUDE_DIR和ZLIB_LIBRARY。这两个为空，说明 find 没找到 zlib，后面编译一定会卡在zlib.h找不到。这时候不要急着改CMakeLists.txt，先确认你的路径里确实有zlib.h和zlib.lib，再确认路径分隔符用的是正斜杠或双反斜杠。
第三个查FREETYPE_LIBRARY。freetype 的查找模块在旧版 CMake 里比较倔，有时候能找着头文件找不到库，结果是编过了链接失败。如果它没被填上，直接用-DFREETYPE_LIBRARY=...和-DFREETYPE_INCLUDE_DIRS=...硬指定，比跟 find 模块较劲快。
第四个查所有PODOFO_HAVE_开头的布尔变量。这是 PoDoFo 自己的特性开关，决定哪些依赖是必需、哪些是可选。这一步的取舍直接决定你最终的库要拖几个 dll，第 4 章会细讲。
3. 依赖链先编干净：zlib、libjpeg、freetype 的 x86 静态库怎么出
3.1 依赖必须同位数、同运行时库、同字符集
这条听上去像废话，但它是老工具链上最常见的翻车源。三个「同」里任何一个不同，症状都不一样：位数不同表现为 LNK2019 或 LNK1112；运行时库不同表现为 LNK2038 或运行期堆损坏；字符集不同（一个/D_UNICODE一个没有）在 PoDoFo 这种大量用std::string的库里影响不大，但在你自己的封装层会出现莫名其妙的路径乱码。
更隐蔽的是「Debug 依赖配 Release 主库」。zlib 的 Debug 版本带_DEBUG宏和调试堆，而 Release 的 podofo.lib 用的是另一套分配器，运行到某个free就会炸。所以我的习惯是依赖也出两套，Debug 加d后缀，和主库的CMAKE_DEBUG_POSTFIX对齐。
还有一件事要提前确认：你的命令行到底是不是 32 位。在 VS2013 的开发者命令提示符里敲cl，输出的第一行会写明是 for x86 还是 for x64。VS2013 的默认快捷方式通常指向 x86，但如果你之前装过别的工具集，快捷方式可能被改过。这一步花十秒，能省掉半小时的 LNK1112 排查。
3.2 zlib：用官方 makefile 走 nmake，别自己搭工程
zlib 源码包里自带win32/Makefile.msc，这是最省事的路。进到源码根目录，在 32 位命令提示符下执行：
# 进入 zlib 源码根目录后执行，产物在根目录 nmake -f win32/Makefile.msc # 如果要静态库且不带调试信息，可以覆盖 CFLAGS nmake -f win32/Makefile.msc CFLAGS="-nologo -MD -O2 -DNDEBUG" ^ OBJA="adler32.obj compress.obj crc32.obj deflate.obj gzclose.obj gzlib.obj gzread.obj gzwrite.obj infback.obj inflate.obj inftrees.obj trees.obj uncompr.obj zutil.obj"第一条命令会同时产出zlib.lib（静态导入库）和zlib1.dll。第二条演示了怎么覆盖CFLAGS：-MD对应动态 CRT，和主库保持一致；如果你的宿主是/MT，把这里换成-MT，-DNDEBUG保留。OBJA那一长串是目标文件清单，正常情况下不用动，写出来是为了说明——如果你只想要静态库不想要 dll，可以只保留zlib.lib相关的构建规则，把 dll 的规则从 makefile 里剔掉，产物目录会干净很多。
编完检查两件事：dumpbin /headers zlib.lib | findstr machine应该看到14C machine (x86)；dumpbin /directives zlib.lib | findstr -i runtime应该只看到MD_或MT_其中一种，混着出现说明你编了两遍没清干净。
3.3 libjpeg：两条路，看你的源码包给的是哪份
老版本的 libjpeg 源码根目录有makefile.vc，配合jconfig.vc使用，命令是nmake -f makefile.vc nodebug=1，产出libjpeg.lib。这条路最稳，但产物只有一个 Release 版本，nodebug=1的意思是不生成调试版。
如果你拿到的是 libjpeg-turbo 那种带 CMake 的源码，就走 CMake，注意三个开关：-DENABLE_SHARED=OFF只要静态库，-DWITH_TURBOJPEG=OFF关掉 turbojpeg 那个额外 API，-DWITH_SIMD=OFF关掉 SIMD。最后这个是重点，SIMD 优化需要 nasm 汇编器，老机器上十有八九没装，开了就卡在nasm not found，而 pdf 文档里的图片解码根本不是你的性能瓶颈，关掉毫无损失。
# CMake 路线，输出到 D:/work/deps/jpeg cmake ^ -G "Visual Studio 12 2013" -A Win32 ^ -DENABLE_SHARED=OFF ^ -DWITH_TURBOJPEG=OFF ^ -DWITH_SIMD=OFF ^ -DCMAKE_INSTALL_PREFIX="D:/work/deps/jpeg" ^ ../libjpeg-src cmake --build . --config Release --target install cmake --build . --config Debug --target install--target install会把头文件和库按标准布局放好，比你去 build 目录里翻Release/jpeg.lib整齐。装完之后D:/work/deps/jpeg/include下应该有jpeglib.h、jconfig.h、jmorecfg.h三个文件，缺jconfig.h的话说明 install 规则没跑全，编译时会报一堆重复定义。
3.4 freetype：CMake 出静态库，但要关掉四个可选模块
freetype 的依赖链比前两个长，默认会去找 zlib、bzip2、png、harfbuzz、brotli，找不到就跳过，但它的 CMake 脚本有时候会「找到一半」，导致配置成功、编译失败。稳妥做法是主动关掉不需要的，只保留 zlib（PoDoFo 也用 zlib，复用一份就行）。
cmake ^ -G "Visual Studio 12 2013" -A Win32 ^ -DBUILD_SHARED_LIBS=OFF ^ -DFT_DISABLE_BZIP2=TRUE ^ -DFT_DISABLE_HARFBUZZ=TRUE ^ -DFT_DISABLE_PNG=TRUE ^ -DFT_DISABLE_BROTLI=TRUE ^ -DZLIB_INCLUDE_DIR="D:/work/deps/zlib/include" ^ -DZLIB_LIBRARY="D:/work/deps/zlib/lib/zlib.lib" ^ ../freetype-src cmake --build . --config Release cmake --build . --config DebugFT_DISABLE_*这几个变量名在不同版本的 freetype 里略有出入，早期版本可能没有FT_DISABLE_BROTLI，配置时如果提示「manually-specified variables were not used by the project」，把不认的那个删掉即可，其余照常生效。这里要特别注意：freetype 的库名在 Windows 上默认是freetype.lib，但有些版本会出freetype_a.lib（静态）和freetype.lib（导入库）两个，你给 PoDoFo 指定路径的时候别指错。
头文件路径有个坑要提前记着：freetype 对外只暴露ft2build.h，其余头文件要通过宏去包含，所以给 CMake 的 include 目录必须是include根目录，不能是include/freetype。PoDoFo 内部也是按#include <ft2build.h>写的，路径指错就会报无法打开包括文件: "ft2build.h"。
3.5 一张表把依赖关系钉死
| 依赖 | 头文件目录 | 库文件名（Release/Debug） | 是否必需 | 备注 |
|---|---|---|---|---|
| zlib | deps/zlib/include | zlib.lib/zlibd.lib | 必需 | PoDoFo 压缩流的基础，不能省 |
| libjpeg | deps/jpeg/include | jpeg.lib/jpegd.lib | 处理含图 PDF 时必需 | 不处理图片可关 |
| freetype | deps/freetype/include | freetype.lib/freetyped.lib | 渲染/嵌字体时必需 | 只做拆分合并可关 |
| libtiff | deps/tiff/include | tiff.lib/tiffd.lib | 可选 | 关掉能少一个 dll |
| libpng | deps/png/include | libpng16.lib/libpng16d.lib | 可选 | 同上 |
| openssl | deps/openssl/include | libssl.liblibcrypto.lib | 可选 | 只需加密 PDF 时才开 |
这张表的价值在于：它决定了你最终分发时要带几个文件。全开的话，一个 32 位程序目录里能多出五六个 dll；只做「合并、拆分、加水印、读元数据」这类操作，把 tiff、png、openssl、lua 全关掉，只剩 zlib 和 freetype，体积立刻下来。
4. 关掉不需要的开关：PoDoFo 的 CMake 选项与命令行编译
4.1 决定产物形态的五个开关
PODOFO_BUILD_LIB_ONLY是最该打开的一个。它让构建系统只编库，跳过 tools 和 examples。那些工具会引入额外的依赖判断（比如某个工具需要 boost），一旦某个工具编不过，整个构建就停在那儿，而你要的只是那个 lib。打开它，等于把失败面收窄到库本身。
PODOFO_BUILD_SHARED和PODOFO_BUILD_STATIC决定出 dll 还是静态库。这里有个要命的细节：两个同时开的时候，某些版本会出现 Debug 下.lib同名覆盖，你以为是静态库，其实拿到的是 dll 的导入库，链接时一路编过，运行时报「找不到 podofo.dll」。我的做法是一次只出一种，要两种就分两个 build 目录。
剩下的是PODOFO_HAVE_*系列，它们控制对 jpeg、tiff、png、openssl、lua、boost 的支持。这里不要凭记忆写死变量名——0.9.x 系列不同小版本的命名有过调整。正确姿势是先生成一遍工程，用 CMake GUI 展开缓存，搜PODOFO_HAVE，看实际列出哪些，再把不需要的置 OFF。这样即使变量名和文档对不上，你也不会配了个寂寞。
还有PODOFO_HAVE_UNISTD_H这类平台探测宏。CMake 在 Windows 上理论上应该把它判成不存在，但如果你在 MSYS 或 MinGW 环境里配过一次，缓存里可能残留一个 ON，然后编译立刻报unistd.h找不到。这个坑第 5 章单独讲。
4.2 命令行增量编译与产物定位
配置好之后不要急着开 IDE，用命令行编一遍，看错误信息更干净，也方便脚本化。
# 在 build 目录下 cmake --build . --config Release --target podofo cmake --build . --config Debug --target podofo # 确认产物 dir /s /b *.lib--target podofo指定只编库这个目标，比不带 target 快很多；--config对 VS 这种多配置生成器是必须的，不带它默认编 Debug。编译失败时，命令行会把出错的文件和行号直接打出来，比 IDE 的「错误列表」窗口少一层干扰，尤其是模板报错。
产物位置通常在build/src/Release/podofo.lib和build/src/Debug/podofod.lib，具体取决于源码里LIBRARY_OUTPUT_DIRECTORY怎么设的。用dir /s /b *.lib扫一遍最省心。拿到之后先做一次体检：
dumpbin /headers podofo.lib | findstr machine dumpbin /directives podofo.lib | findstr -i runtime第一条确认是14C machine (x86)，第二条确认 CRT 只有一种。这两条过不了，后面无论怎么写代码都白搭。
4.3 Debug 和 Release 两套产物怎么共存
CMAKE_DEBUG_POSTFIX=d就是为了这个。它在 Debug 配置下给库名加后缀，得到podofod.lib，和 Release 的podofo.lib放在同一目录也不冲突。但要注意，这个名字后缀只影响库文件名，不影响导出符号，所以你不能在一个进程里同时链接两个版本——那会导致 CRT 堆混用，症状是随机的崩溃或内存泄漏报告。
我的目录习惯是分开放：build/v120-x86/Release和build/v120-x86/Debug各自 install 到deps/podofo/release和deps/podofo/debug，头文件共用一份。这样在 VS 工程里切换配置时，用属性表把 include 固定、lib 目录跟着配置走，就不会出现「Debug 编过了但链接的是 Release 库」这种玄学问题。
4.4 静态库和动态库同时出时注意符号导出
如果你确实需要两种形态，注意 PoDoFo 在 Windows 上有导出宏控制。出 dll 时需要PODOFO_EXPORTS之类的宏参与编译，出静态库时不能带。混在一个 build 目录里，缓存会被污染，最典型的表现是你明明编的是静态库，链接时却提示__imp_前缀的符号找不到。
解决办法不复杂：两个 build 目录，两套缓存，互不干扰。多花几秒配置时间，比事后清理缓存重编划算。
5. 编译期和链接期的排查清单：五类翻车现场
5.1 C1083 找不到 unistd.h
现象：编到一半突然报fatal error C1083: 无法打开包括文件: "unistd.h": No such file or directory，出错的文件往往是 PoDoFo 内部某个处理文件名或流的源文件。
原因：podofo-config.h里PODOFO_HAVE_UNISTD_H被定义成了 1。这个头文件是 CMake 在配置阶段生成的，如果之前用 MinGW、MSYS 或者在别的机器上配过同一个 build 目录，缓存里留着旧的探测结果，就会带进来。
解决：打开 CMake GUI，取消勾选PODOFO_HAVE_UNISTD_H，重新 Generate；或者干脆删掉CMakeCache.txt和podofo-config.h重新配。删缓存这个动作，在老工具链迁移场景里能解决掉一半的玄学问题，别舍不得。
5.2 LNK2038 检测到 RuntimeLibrary 不匹配
现象：链接时报LNK2038: 检测到 "RuntimeLibrary" 的不匹配: 值 "MD_DynamicRelease" 与值 "MT_StaticRelease" 不匹配，后面跟着一个.obj文件名。
原因：主库和某个依赖库的 CRT 链接方式不一致。常见组合是你把 PoDoFo 配成了/MD，但 zlib 是用默认参数nmake编出来的——zlib 的Makefile.msc里默认-MD，理论一致，但如果之前手工改过或用了不同版本的 makefile，就会漂移。
解决：先看报错里点名的那个.obj是哪个库贡献的，把那个库按同样的CFLAGS重编一遍。三个依赖 + 主库，四个的dumpbin /directives输出必须一致。这一步没有捷径，只能逐个对。
5.3 C4819 代码页 936 警告刷屏，然后变成 C2001
现象：编译输出里几百行warning C4819: 该文件包含不能在当前代码页(936)中表示的字符，警告看多了没人管，直到某天出现error C2001: 常量中有换行符。
原因：PoDoFo 源码里有些文件是 UTF-8 编码且不带 BOM，VS2013 在中文代码页下按 GBK 解析，遇到非 ASCII 字符就当成乱码，严重时把字符串字面量的引号吃掉了，就变成 C2001。
解决：最简单的是给这几个文件加 UTF-8 BOM，VS2013 认 BOM。注意 VS2013 不支持/utf-8编译选项（那是后来才有的），别在这上面找方案。如果你的源码是只读的版本管理副本，改完记得标注一下，不然下次拉代码又回来了。
5.4 LNK2019 未解析的外部符号，通常指向 jpeg 或 freetype
现象：LNK2019: 无法解析的外部符号 _jpeg_std_error，或者_FT_Init_FreeType。
原因：三种可能。一是 CMake 找到了头文件但没找到库，PODOFO_HAVE_JPEG仍然是 OFF，PoDoFo 内部走的是空实现，但你的代码调了带图接口。二是路径指对了但库的位数不对，x64 的 lib 混进了 x86 工程，这种情况下报错里通常还夹着 LNK1112。三是库名对不上，比如 freetype 产出的是freetype_a.lib而你链接的是freetype.lib。
解决：先确认podofo-config.h里对应宏是 1；再dumpbin /headers看依赖库的 machine 字段；最后检查 lib 目录里到底有哪几个文件。三步按顺序走，基本一次定位。
5.5 编出来能链接，运行时缺 dll 或一调就崩
现象：程序启动就弹「找不到 zlib1.dll」，或者跑到doc.Save()时崩溃。
原因：缺 dll 是因为你链接的是导入库，实际依赖动态库；崩溃则多半是 Debug/Release 混链，或者异常没接住——PoDoFo 用PdfError抛异常，很多接口失败时直接 throw，不接就是 terminate。
解决：缺 dll 的话，把三个依赖的 dll 一起放进 exe 目录，或者改成静态链接；崩溃的话，在所有 PoDoFo 调用外面套try { ... } catch (PdfError& e) { e.PrintError(); }，先把错误码打出来，再判断是文件本身有问题还是你参数传错。这个 try-catch 我建议从第一个测试程序就加上，它是唯一的黑匣子。
6. 把 podofo.lib 接进你的 x86 工程：最小验证与裁剪
接到宿主工程时，属性表里要配的东西不复杂，但容易漏。C/C++ 的附加包含目录至少要有三份：PoDoFo 的include、以及它的build目录（因为podofo-config.h是生成在那里的，不在源码树里）。链接器的附加依赖项按顺序写podofo.lib;freetype.lib;jpeg.lib;zlib.lib，如果用了 openssl 再加两个。
先用一个最小程序验证链路通不通，别一上来就往业务代码里塞：
#include <podofo/podofo.h> #include <iostream> using namespace PoDoFo; int main() { try { PdfMemDocument doc; // A4 页面，单位是 PDF 点（1/72 英寸） PdfPage* pPage = doc.CreatePage(PdfPage::CreateStandardPageSize(ePdfPageSize_A4)); PdfPainter painter; painter.SetPage(pPage); painter.SetFontSize(24); painter.DrawText(56.0, 780.0, "PoDoFo 0.9.5 / v120 / x86"); painter.FinishPage(); doc.Save("smoke.pdf"); // 回读一次，确认写出来的东西自己认得 PdfMemDocument reload; reload.Load("smoke.pdf"); std::cout << "pages=" << reload.GetPageCount() << std::endl; } catch (PdfError& e) { e.PrintError(); return 1; } return 0; }这段代码干了三件事：建页、画字、存盘，然后重新打开读页数。三件事都过，说明 libjpeg、freetype、zlib 的符号都解析成功，CRT 也没打架。CreateStandardPageSize返回的是PdfRect，SetFontSize和DrawText的单位都是点，坐标原点在左下角，所以 y 给 780 是靠近页面顶部。如果你的分支里这几个方法名有出入，用 IDE 的「转到定义」确认一下签名再改，别硬套。
裁剪是下一步。我一般会做一张表，把「关掉哪个开关 → 少几个依赖 → 损失什么能力」列清楚，按业务实际需要砍。只做合并拆分加水印的项目，PODOFO_HAVE_TIFF、PODOFO_HAVE_PNG、PODOFO_HAVE_OPENSSL、PODOFO_HAVE_LUA全关，PODOFO_HAVE_JPEG视情况保留。关掉之后重新编，dumpbin /dependents看 exe 的依赖列表，正常情况下应该只剩系统 dll 加 zlib。
最后一件事，也是我踩过最疼的一次：在源码目录里直接cmake .，把生成文件全撒在源码树里，后来想换个配置重新配，缓存和旧的podofo-config.h互相打脸，查了两小时才发现是缓存残留。从那次之后我的规矩是「源码目录只读，构建目录一次性，配置错了就整个删掉重来」。这个习惯看着笨，但它替我省下的时间比任何优化技巧都多。
希望帮到你。
本文还有配套的精品资源，点击获取
