企业官网建设流程全解析

简介：icu4c-56_1-Win64-msvc10.zip 面向在 Windows 64 位、Visual Studio 2010（msvc10）环境下编译 Tesseract OCR 并希望增强多语言识别能力的开发者，提供可集成到本地工程的 ICU 56.1 库文件。压缩包共 220 个文件、约 12.9MB，包含 182 个头文件与 7 个 lib 库文件，另有 8 个 dll、15 个 exe 工具及 exp、license.html 等，分别服务于接口声明、静态或动态链接、运行期依赖、命令行工具和许可说明。已有 599 人学习，适合正在处理中文、日文、韩文等非拉丁字符集 OCR 项目的开发者参考。借助 bin、include、lib 的完整目录，读者可配合 CMake 设置头文件路径、库搜索路径与链接选项，排查依赖缺失、运行时库版本不匹配、字符集转换异常等问题，并理解 ICU 在字符串处理、文本排序与本地化格式中的辅助作用，提升 Tesseract 国际化文本识别与工程构建效率。目录按头文件、库文件与工具分类，便于在项目中快速定位和复用。

1. 从一次 0xc000007b 说起：ICU 56.1 这套 Win64 二进制到底装给谁

上季度在一台 Win10 机器上复现 OCR 流程，Tesseract 编译一路绿灯，双击产物直接弹 0xc000007b。查了大半天不是代码问题，是 icu4c-56_1-Win64-msvc10.zip 解压出来的 DLL 被一个 32 位老路径抢先加载了。ICU 在 Tesseract 的依赖链里属于那种平时不起眼的环节：CMake 里就 find_package(ICU) 一行，可版本、位数、运行库三样里错一样，报错信息全指向别处。

这套 Win64 + MSVC10 的预编译包，是很多人给 Tesseract 配 Unicode 支持时最省事的选择，也是最容易出意外情况的。下面按实际装机的顺序，从选包、铺目录、接进 CMake 到运行出问题怎么救，完整走一遍。

2. 装前把版本钉死：ICU 56.1、MSVC10、x64 三件套的匹配关系

2.1 ICU 4C 在 Tesseract 里到底干什么活

很多人以为 OCR 只跟图像打交道，字符集的事交给操作系统就行。真拆开 Tesseract 的源码看，ICU 的调用点密集得超出预期：判断一个码位是字母还是标点、把全角字符归一化、做大小写的区域敏感转换、按 Unicode 规则断词、识别文本方向、处理组合字符序列，全靠 ICU 的字符属性表和转换器。Tesseract 内部把识别结果拼成 UTF-8 之前，中间那一层 unichar 的语义判断基本是 ICU 在兜底。

这也解释了为什么 ICU 缺了不是「少个功能」，而是整个链路在运行时找不到符号。你会在链接期看到一堆 u_strToUTF8、u_charType、ucnv_open 之类的 unresolved external，或者干脆编译过了、跑起来加载 DLL 时直接挂掉。ICU 4C 的名字里 4C 指 C 接口那一套，Tesseract 用的主要就是这套 C API，只有少量地方碰了 icu:: 命名空间下的 C++ 类，这个细节在后面讲版本混用时非常关键。

所以装 ICU 这件事，真正的目标不是「把压缩包解开」，而是让 CMake 能找到头文件、让链接器能找到 import lib、让运行时能找到三个 DLL。三件事任缺一件，都会以完全不同的报错形式出现，很容易把人带偏。

2.2 为什么很多项目还锁在 56.1，而不是最新版

ICU 56.1 对应 Unicode 8.0，是 2015 年前后的版本。放到今天看它很老，但在这条依赖链上有它不可替代的位置。

第一是工具集。官方发布的 Windows 预编译二进制是按 Visual Studio 版本分批的，msvc10 对应 VS2010 的 v100 工具集。往后的版本，官方包的工具集一路往上走，msvc10 这一档早就停了。手上如果是一个必须用 VS2010 编译的老工程，56.1 几乎是能直接拿来用的最后一档。

第二是 API 稳定性。ICU 在大版本之间做过几次清理，一些早期接口在新版里被标记废弃甚至移除，行为也有微调。Tesseract 的老分支是按 5x 系列的语义写的，换上 60 以后的版本，多数情况能编过，但个别边界行为会变。做迁移的人最怕这种「编过了但结果不一样」，所以宁可锁版本。

第三是数据版本匹配。ICU 的字符数据跟着 Unicode 版本走，56.1 是 Unicode 8.0。如果训练数据、字典、语言模型都是那个年代产出的，用同代 ICU 省掉一轮「为什么某些生僻字分类变了」的排查。

提示：如果你用的是 Tesseract 5 这类较新分支，它自己的 CMake 里对 ICU 有最低版本要求（按我的记忆是 52.1 起步），56.1 刚好过线。想上更新的 ICU 不是不行，但那就得自己从源码编，还得配好对应的工具集，工作量完全不是一个量级。

2.3 MSVC10 编出来的库，拿到 VS2015/2019 里链接会发生什么

这是最多人问的一个问题，答案要分两种情况。

如果代码只调 ICU 的 C API，那基本安全。ICU 的 import lib 导出的是 C 符号，不带 C++ 的修饰名，MSVC 各版本对 C 符号的处理是一致的，链接器不会因为工具集不同就拒绝。你在 VS2019 的 x64 Release 配置下链接 msvc10 编译出来的 icuuc.lib，能过，能跑。

一旦代码碰了 icu:: 下的 C++ 类，风险立刻上来。最典型的是 LNK2038，报 _ITERATOR_DEBUG_LEVEL 不匹配：你的工程是 Debug 配置，MSVC 默认把 _ITERATOR_DEBUG_LEVEL 定成 2，而预编译的 ICU release 库是 0，两边的 STL 布局假设不同。这条错误只在实例化 ICU 的 C++ 模板类时才会被触发，所以有的人编过了、有的人编不过，看起来像难以复现的问题。

还有一层更隐蔽的：跨 CRT 的堆分配。ICU 内部 malloc 出来的缓冲区，如果交给你的代码 free，而两边 CRT 版本或 /MD、/MT 选项不一致，堆句柄不是一个，崩溃点会飘到你完全想不到的地方。合格的做法是只使用 ICU 提供的释放函数（比如 ucnv_close 对应的资源就用 ucnv_close 释放），不要自己去 free 它返回的东西。

我的取舍很直接：能用 C API 就用 C API；确实需要 C++ 接口，就统一工具集，或者干脆用和工程一致的 VS 版本从源码编一份 ICU。混着用不是不行，是出问题的时候排查成本太高。

2.4 解压前先认清包里每个文件的用途

把 icu4c-56_1-Win64-msvc10.zip 解开，能看到的东西不多，但每个都有明确分工：

三个 .lib 都是 import lib，不是静态库，意味着最终产物必须带 DLL 才能跑。icudt 这一份容易被忽略：56 这一代的 Windows 官方包默认把数据打包进 icudt56.dll（打包方式为 library），所以它既是数据也是运行期依赖，少一个都起不来。至于 DLL 到底躺在 lib 目录还是单独的 bin 目录，不同批次打包略有差别，解压完先 Get-ChildItem 扫一遍再往下走，别凭印象写路径。

3. 落地安装：把 icu4c-56_1 铺到磁盘并接进 CMake

3.1 目录规划：路径不带空格、不带中文

这一步听起来像废话，实际是后面一半玄学问题的源头。CMake 生成的工程文件里，库路径是原样写进去的，路径里带空格，某些生成器会在链接行上少加引号，报错长得像「找不到文件」但文件名明明是完整的。带中文的路径在部分工具链上还会遇到编码问题。

我的习惯是统一放在 D:\dev\ 下面，按库名和版本分层，版本号单独一层目录，将来并排放 56.1 和别的版本互不干扰。

# 目标目录：D:\dev\icu\56.1，全程无空格无中文 $zip = "D:\pkg\icu4c-56_1-Win64-msvc10.zip" $dst = "D:\dev\icu\56.1" New-Item -ItemType Directory -Force -Path $dst | Out-Null # -Force 覆盖已有内容，重复解压不会报错 Expand-Archive -Path $zip -DestinationPath $dst -Force # 解压完先核对两件事：头文件在不在、lib 和 dll 各有几个 Test-Path "$dst\include\unicode\uversion.h" Get-ChildItem "$dst\lib" -Filter *.lib | Select-Object Name, Length Get-ChildItem "$dst" -Recurse -Filter *.dll | Select-Object FullName

Expand-Archive 的 -DestinationPath 不会自动创建多层父目录，所以前面先用 New-Item 铺好。三行检查命令建议每次都跑：uversion.h 存在说明 include 结构是对的，.lib 列出三个说明 import lib 齐了，.dll 的 FullName 决定后面 PATH 和 POST_BUILD 里该写哪个目录。

如果解压出来多了一层同名目录（比如 D:\dev\icu\56.1\icu\include），别急着改脚本，直接把目标目录定到那一层，或者用 Move-Item 提上来。层级错一位，后面 CMake 找不到 ICU 的时候你会怀疑人生。

3.2 三个环境变量：ICU_ROOT 给 CMake，PATH 给 exe，ICU_DATA 多数时候不用管

CMake 从 3.7 起自带 FindICU 模块，它优先读 CMake 变量 ICU_ROOT，其次读同名环境变量。所以第一件事是把 ICU_ROOT 设成安装根目录，注意是根目录，不是 include 也不是 lib。

# 永久写入用户环境变量，新开的终端才生效 setx ICU_ROOT "D:\dev\icu\56.1" # PATH 里追加 DLL 所在目录，注意用分号分隔且不要覆盖原值 $icuBin = "D:\dev\icu\56.1\lib" $old = [Environment]::GetEnvironmentVariable("Path", "User") [Environment]::SetEnvironmentVariable("Path", "$old;$icuBin", "User") # 验证：新开一个终端里执行 echo $env:ICU_ROOT where.exe icuuc56.dll

setx 有个坑：它写的是注册表里的用户变量，当前已经打开的终端读不到，必须新开窗口。很多人设完立刻回去跑 cmake，发现还是找不到，就是因为这个。第二条用 .NET 的方式追加 PATH 而不是 setx PATH "%PATH%;..."，是为了避免把系统级 PATH 展开后写死到用户变量里，那个操作做错一次很难还原。

ICU_DATA 这个变量在 56 这一代基本不用设，因为数据已经打进 icudt56.dll，ICU 内部有编译期固化的路径。只有当你拿到的是 data 单独发布、以 .dat 文件形式存在的包时，才需要把它指向文件所在目录。看到网上教程让你设 ICU_DATA，先确认自己手里是哪种包。

提示：PATH 里如果已经存在别的 ICU 版本目录，加载顺序会按 PATH 从左到右走。icuuc56.dll 这种带版本号的还好，最怕的是有人把 DLL 改名成不带版本号的形式，那就全靠顺序决定加载谁，出问题极难查。

3.3 先用一个 CMake 探针确认 FindICU 认得它

不要一上来就配 Tesseract。先建一个只有几行的独立工程，专门验证 FindICU 能不能定位到这套 56.1。这一步花两分钟，能省掉后面在几千行构建日志里翻找的时间。

cmake_minimum_required(VERSION 3.10) project(icu_probe CXX) # 只找 uc 和 i18n。56.1 的预编译包里没有独立的 data 组件库， # 写 COMPONENTS data 反而会让 FindICU 判定失败 find_package(ICU 56 REQUIRED COMPONENTS uc i18n) message(STATUS "ICU_VERSION = ${ICU_VERSION}") message(STATUS "ICU_INCLUDE_DIRS = ${ICU_INCLUDE_DIRS}") message(STATUS "ICU_LIBRARIES = ${ICU_LIBRARIES}")

三个 message 是有意打的。ICU_VERSION 会从 uversion.h 里解析出来，能打印出 56.1 说明头文件路径正确；ICU_INCLUDE_DIRS 应该指向 D:/dev/icu/56.1/include；ICU_LIBRARIES 里应该出现 icuuc.lib 和 icuin.lib 的完整路径。如果版本号打出来是空的但路径对，通常是 FindICU 解析头文件时没找到 uvernum.h，检查 include 层级有没有多套一层。

配置命令这样跑：

# 在探针工程目录下执行，生成目录单独放，方便出问题直接删 cmake -S . -B build-probe -G "Visual Studio 16 2019" -A x64 -DICU_ROOT="D:/dev/icu/56.1"

-G 指定生成器，-A x64 指定目标平台。这两个参数决定了后面链接的是 64 位库还是 32 位库，写错就是经典的位数不匹配。ICU_ROOT 这里再显式传一次，是为了让工程自带一份可复现的配置，不依赖某台机器的环境变量。

3.4 FindICU 失灵时的退路：手写三个变量

FindICU 不是万能的，尤其是路径不规范、版本号和目录名对不上、或者 CMake 版本偏老的时候。这时候别在那边反复删缓存，直接把三个变量写死传进去更快。

cmake -S . -B build-probe -G "Visual Studio 16 2019" -A x64 ` -DICU_INCLUDE_DIR="D:/dev/icu/56.1/include" ` -DICU_UC_LIBRARY_RELEASE="D:/dev/icu/56.1/lib/icuuc.lib" ` -DICU_I18N_LIBRARY_RELEASE="D:/dev/icu/56.1/lib/icuin.lib"

三个变量的含义分别是头文件根目录、common 库的 release import lib、i18n 库的 release import lib。注意变量名里带 RELEASE 后缀，这是因为 FindICU 支持 Debug 和 Release 分开配置。这套包里只有 release 版库，所以只传 RELEASE 那一组；如果 CMake 在 Debug 配置下找不到对应的 debug 库，它会回退到 release，多数情况没问题。

还有一条路是 pkg-config，但在 Windows 上要额外装 pkg-config 并配 PKG_CONFIG_PATH，为了一个库不值当。我的排序是：环境变量 → 显式传参 → 手写变量，三级退路够用了。

4. Tesseract 联动：编译期链接和运行期 DLL 是两套配置

4.1 Tesseract 的 CMake 配置命令逐项拆解

探针跑通之后，再来配 Tesseract 本体。它自己的 CMakeLists 里有一段 find_package(ICU ...)，走的是同一套 FindICU 逻辑，所以只要 ICU_ROOT 生效，ICU 这一环基本不用额外操心。真正耗时的是它另一个依赖：图像处理库。这部分不在 icu4c 这个包里，得提前备好，否则 CMake 会在配置阶段就停下。

# 在 Tesseract 源码根目录执行 cmake -S . -B build -G "Visual Studio 16 2019" -A x64 ` -DICU_ROOT="D:/dev/icu/56.1" ` -DCMAKE_PREFIX_PATH="D:/dev/icu/56.1;D:/dev/leptonica/install" ` -DCMAKE_INSTALL_PREFIX="D:/dev/tesseract/install" ` -DBUILD_SHARED_LIBS=OFF ` -DCMAKE_BUILD_TYPE=Release

逐项说：

• ICU_ROOT 和探针里一样，指向 ICU 根目录。
• CMAKE_PREFIX_PATH 是给那些没有专门 Find 模块的依赖用的，多个路径用分号分隔。把 ICU 也放进去是双保险，某些版本的查找逻辑会先扫 PREFIX_PATH。
• CMAKE_INSTALL_PREFIX 决定 install 目标把产物放到哪，建议指到独立目录，不要和源码混。
• BUILD_SHARED_LIBS=OFF 表示编静态的 tesseract 库。这一项和 ICU 无关，但会影响最终产物是否需要附带一堆 DLL，一开始就定下来省得返工。
• CMAKE_BUILD_TYPE 对 VS 这类多配置生成器其实不生效，真正的配置由构建时的 --config 决定，写在这里是给单配置生成器留的兼容。

配置完成后构建：

cmake --build build --config Release --target install

--config Release 是关键，多配置生成器默认可能走 Debug。用 Debug 配置去链 release 的 ICU，就是 2.3 里说的那类不匹配问题的温床。

4.2 运行期：DLL 到底从哪个目录被加载

编译期的路径写在工程文件里，运行期的搜索完全是另一套规则。Windows 加载 DLL 的顺序大致是：exe 所在目录 → 系统目录 → PATH 里的目录。注意 exe 同目录的优先级高于 PATH，这意味着你把 ICU 的 DLL 拷到产物旁边，就永远不用管 PATH 里有没有别的版本。

反过来，如果 exe 旁边没有，PATH 里又有两个不同版本的 icuuc 同名 DLL（比如别人把 56 的改名成了不带版本号的），加载到哪个就完全看 PATH 顺序，这类问题排查起来极其费劲。我见过最离谱的一次，同一份 exe 在两台机器上表现完全不同，最后发现是其中一台的 PATH 里挂着一个旧版 ICU 的目录。

所以部署策略我固定成一条：把 icuuc56.dll、icuin56.dll、icudt56.dll 三个文件拷到 exe 同级目录，PATH 只作为开发期的方便手段，不作为交付依赖。

4.3 用 POST_BUILD 把拷 DLL 这件事自动化

手工拷迟早会忘，尤其是清理重建之后。CMake 的 POST_BUILD 自定义命令可以挂在目标上，每次构建完自动同步，而且 copy_if_different 会跳过没变化的文件，不拖慢构建。

# 放在 tesseract 可执行目标定义之后 set(ICU_DLL_DIR "D:/dev/icu/56.1/lib") # 按实际解压位置改 foreach(dll_name icuuc56 icuin56 icudt56) add_custom_command(TARGET tesseract_cli POST_BUILD COMMAND ${CMAKE_COMMAND} -E copy_if_different "${ICU_DLL_DIR}/${dll_name}.dll" "$<TARGET_FILE_DIR:tesseract_cli>" COMMENT "copy ${dll_name}.dll") endforeach()

foreach 遍历三个 DLL 名，避免写三遍几乎一样的命令。$<TARGET_FILE_DIR:目标名> 是生成器表达式，在构建时展开成该目标产物的实际目录，这样 Debug 和 Release 各自的输出目录都能对上，不用手写 build\bin\Release 这种硬路径。copy_if_different 在源文件比目标新或者目标不存在时才真正复制，重复构建几乎零开销。

如果 DLL 实际躺在解压目录的 bin 而不是 lib，把 ICU_DLL_DIR 改过去就行，这是唯一需要按实际情况调整的地方。

4.4 别急着跑 OCR，先跑一个二十行的 ICU 小程序

在 Tesseract 上排查 ICU 问题，日志会被各种图像处理的输出淹掉。更快的办法是单独编一个小程序，只调 ICU，确认版本、字符属性、链接都对。

#include <unicode/uchar.h> #include <unicode/uversion.h> #include <cstdio> int main() { UVersionInfo ver; u_getVersion(ver); // 运行时 ICU 版本，不是编译期头文件的版本 char buf[U_MAX_VERSION_STRING_LENGTH]; u_versionToString(ver, buf); std::printf("runtime ICU: %s\n", buf); // 取“中”字的 Unicode 通用类别，正常应返回 U_OTHER_LETTER int32_t t = u_charType(0x4E2D); std::printf("U+4E2D category = %d\n", static_cast<int>(t)); return 0; }

配套的 CMake 只要两行：add_executable，然后 target_link_libraries 链 ${ICU_LIBRARIES}。这个程序能跑起来，说明头文件、import lib、DLL 三段链路全通。特别注意 u_getVersion 打印的是运行期加载到的那个 DLL 的版本，拿它和头文件里的 U_ICU_VERSION 对一下，两者不一致就说明运行时加载到了别的 ICU，这是最容易漏掉的一类错配。

5. 排查：ICU、Tesseract、CMake 组合里最常见的五个翻车点

5.1 程序一启动就 0xc000007b

现象：编译零警告，双击 exe 或命令行启动立刻报 0xc000007b（应用程序无法正常启动），没有任何调用栈。

原因：位数不匹配。64 位 exe 加载了 32 位的 icuuc56.dll，或者反过来。CMake 的 -A x64 只决定目标平台，不决定运行时从哪里加载 DLL，PATH 里挂着一个 32 位 ICU 目录就会出这个结果。另一种可能是 DLL 本身依赖的 CRT 缺失，表现相同。

解决：先用 dumpbin /headers 看 exe 的 machine 字段是不是 x64，再对 DLL 做同样检查，两边必须一致。然后把 exe 同目录的 ICU DLL 换成 64 位那份，并且确认 PATH 里没有别的 ICU 目录抢占。这一步不要靠猜，dumpbin 的输出是确定性的。

5.2 CMake 报 Could NOT find ICU，但环境变量明明设了

现象：配置阶段报找不到 ICU，提示里列出 ICU_ROOT-NOTFOUND，而 echo $env:ICU_ROOT 是有值的。

原因：三种。一是设完环境变量没开新终端；二是 build 目录里的 CMakeCache.txt 已经缓存了上一次的 NOTFOUND 结果，后面再设变量也不会重新探测；三是 ICU_ROOT 指到了 include 或 lib 那一层，而不是根目录。

解决：先删掉整个 build 目录再重配，这是最快的验证方式。然后确认 ICU_ROOT 指向的是包含 include 和 lib 两级的那一层。如果还不行，按 3.4 的方式把三个变量显式传进去，把问题从「查找失败」变成「路径错误」，信息量立刻不一样。

5.3 链接报 LNK2019，符号名是 u_strToUTF8 之类

现象：编译通过，链接阶段一堆 unresolved external symbol，符号名以 u_ 开头。

原因：只链了 icuuc.lib 没链 icuin.lib，或者反过来。也有些工程自己手写了 find_library 只找了一个库。还有一种少见情况：链接行里同时出现 32 位和 64 位两个 ICU 的 lib，先找到的那个负责解析，剩下的符号全成未定义。

解决：看符号属于哪个库——字符属性、字符串转换在 common（icuuc），格式化、断词、排序在 i18n（icuin）。最省事的做法是直接用 ${ICU_LIBRARIES}，让 FindICU 把两个都带上。如果必须手写，两个 .lib 都写上，顺序放在其他依赖之前。

5.4 LNK2038：_ITERATOR_DEBUG_LEVEL 的值不匹配

现象：Debug 配置下链接失败，报 mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0'。

原因：工程用 Debug 配置（_ITERATOR_DEBUG_LEVEL=2），而 ICU 56.1 的官方预编译包只有 Release 版库（=0）。只要代码里实例化了 ICU 的 C++ 类模板，编译器就会检查这个宏。

解决：三条路。一是把工程切到 Release，或者新建一个 Release 配置专门做验证；二是改造代码，只用 C API，不碰 icu:: 命名空间；三是用和工程一致的工具集从源码编一份 Debug 版 ICU。我一般选第二条，改造成本最低，还顺带避开了跨 CRT 释放内存的隐患。

5.5 跑起来报 U_FILE_ACCESS_ERROR 或找不到数据

现象：链接没问题，运行时某个 ICU 调用返回失败，错误码指向文件访问或数据缺失。

原因：icudt56.dll 没跟着部署。很多人只拷了 icuuc56.dll 和 icuin56.dll，觉得 data 不是「库」，结果 ICU 初始化数据的时候找不到打包进去的那份。另一种是误设了 ICU_DATA 指向一个不存在的目录，把原本正确的默认路径覆盖掉了。

解决：把 icudt56.dll 一起拷到 exe 旁边，并且把 ICU_DATA 环境变量清掉（setx ICU_DATA "" 或者直接在系统设置里删）。判断依据很简单：用 4.4 那个探针程序调一次 u_getVersion 能过、调一次涉及数据的函数（比如 u_charType）也过，说明数据和库都到位了。

6. 装完怎么验证：三层自检把 ICU 56.1 真正钉死在链路里

装完不等于装对。我习惯按三层从下往上验，每层都有一个明确的通过标准，这样出问题时能立刻定位到是哪一层断的。

第一层的命令就是 3.3 那个探针的配置输出，重点看两行：ICU_VERSION 和 ICU_LIBRARIES。版本号打出来是 56.1 但库路径指向了别的地方，说明机器上还装着另一份 ICU 且被优先找到，这时候要把 ICU_ROOT 和环境变量都检查一遍。

第二层要留意的是构建日志里有没有警告被忽略。有时候链接能过，但日志里有一行关于库版本冲突的 warning，这种「能过但有隐患」的状态最坑，部署到别的机器上才爆。我一般会把构建日志重定向到文件，grep 一遍 ICU 相关的行。

# 全量构建日志落盘，事后翻查比在终端里滚屏靠谱 cmake --build build --config Release 2>&1 | Tee-Object -FilePath build.log Select-String -Path build.log -Pattern "ICU|LNK|warning" | Select-Object -First 30

第三层是最容易被跳过的一层。跑 4.4 的探针程序，看 u_getVersion 的输出；然后跑 tesseract 的版本命令：

# 确认 tesseract 起来并加载到正确的 ICU .\build\bin\Release\tesseract.exe --version .\build\bin\Release\tesseract.exe --list-langs

--version 的输出里会带上依赖库的版本信息，扫一眼 ICU 那一行是不是 56 系列。--list-langs 能正常列出语言包，说明数据加载路径没问题。这两条都过了，再拿一张小图跑一次识别，观察输出里中文字符的断词和大小写是否正常——这一步是端到端的确认，比任何单元测试都直观。

注意：验证要在「干净终端」里做，把 PATH 里所有跟 ICU 相关的临时目录去掉，只靠 exe 同级目录的 DLL。这样验出来的结果才等于用户机器上的结果。

从那以后我每次配 ICU，都强制先跑一遍那个二十行的探针程序，再动 Tesseract；DLL 一定用 POST_BUILD 自动拷，绝不手工复制。这两条习惯帮我省掉的返工时间，远超当初写脚本花的那半小时。希望帮到你。

本文还有配套的精品资源，点击获取