企业官网建设流程全解析

上周有个做边缘设备的兄弟找到我，说板子上总共就 8MB 的 rootfs，还想跑点图像预处理，开口第一句就是：能不能把 opencv 裁剪到 2Mb。我当时的第一反应是有点狠，因为默认装完的 OpenCV 光一个动态库就几十兆，Python 环境下一装就是几百兆起步。但把他那句需求拆开看——只要缩放、阈值、颜色空间转换，再加个读 JPEG 的入口——这事不仅能干成，我自己前后干过不下五次。这篇就把整个裁剪库的过程、每一处体积从哪儿省出来的、以及最后那点“再抠一抠”的偏方，一次性倒出来。

这篇内容适合三类人看：一是做嵌入式、边缘盒子、工控板，Flash 和 RAM 都紧张，装不下完整 OpenCV 的；二是做 Docker 镜像瘦身、想把 CI 产物塞进小体积基础镜像的；三是虽然不差空间，但想弄明白 OpenCV 到底胖在哪、哪些开关是真有用、哪些是心理安慰的。下面讲的每一组参数都是我在 ARM Cortex-A7 和 x86_64 上都跑过一遍的，数字可能随版本和编译器有出入，但量级和方向是可靠的。

1. 先搞清楚OpenCV的体积到底堆在哪

1.1 模块化设计背后的“默认全量”

OpenCV 的源码结构是按模块划分的，core、imgproc、imgcodecs、videoio、highgui、dnn、features2d、calib3d 一路排下去，官方提供的发行包为了照顾所有人，默认把所有模块都编上，还额外塞了 opencv_contrib 那一堆实验性模块。你在 Linux 上apt install libopencv-dev，装出来的东西之所以吓人，是因为它同时给了静态库、动态库、头文件、pkg-config 描述文件，还有 Python 绑定和 Java 绑定。真正跑起来被你用到的，可能连十分之一都不到。

这就像买了个 200 件的工具箱，你只想拧两颗十字螺丝，结果人家给你配了全套套筒、扭力扳手和内六角。裁剪库的第一步从来不是改编译器参数，而是先明确“我到底要用哪几个功能”，然后只编对应的模块。OpenCV 的 CMake 提供了一个BUILD_LIST变量，直接指定要编的模块名列表，这是所有裁剪手段里性价比最高的一招，通常一步就能砍掉七成以上的体积。

1.2 静态库、调试符号与SIMD分派三座大山

很多人第一次看libopencv_core.a的大小会懵：x86_64 Release 构建下动辄十几兆，imgproc 更大。这里面大头有三块。第一块是调试信息和符号表，Release 模式下虽然不再生成完整调试信息，但符号表还在，.symtab和.strtab加起来能占静态库体积的两三成，strip 之后立刻瘦一圈。第二块是 SIMD 分派，OpenCV 默认会为同一份算法编出 SSE2、SSE4.2、AVX2、AVX512 等多个版本，运行时通过 CPU 特性检测挑一个执行，这在 PC 上是好事，在只需要跑一个固定芯片的嵌入式板子上就是纯浪费。

第三块是第三方依赖。OpenCV 内部打包了一堆外部库：zlib、libjpeg-turbo、libpng、libtiff、libwebp、protobuf、ade、quirc、freetype、harfbuzz，还有 IPP、OpenCL、TBB、OpenMP 这些加速后端。你要是全开，编出来的东西自然小不了。理解这三块之后，裁剪的思路就非常清晰了：砍模块、砍分派、砍依赖、砍符号，四刀下去，几十兆变两三兆是完全现实的。

1.3 2Mb的目标到底现不现实

先要把 2MB 这个数字说清楚，因为它有三种含义：静态链接后的单个可执行文件 2MB、动态库文件 2MB、还是一个压缩包 2MB。这三者难度差得很远。我的实测结论是：只保留 core、imgproc、imgcodecs 三个模块，只支持 JPEG 解码，用-Os加 LTO 加 section 垃圾回收再加 strip，ARM 32 位平台的静态可执行文件能落在 1.6MB 到 2.2MB 之间，x86_64 因为指令编码更长，会略大一丢丢，大概 2.0MB 到 2.6MB。

如果你的需求里出现 dnn 推理、人脸检测、特征点匹配、相机视频流采集，那 2MB 基本不用想，这几个模块背后的依赖太重，protobuf 一个就够你喝一壶。所以判断标准很简单：功能清单里有没有“模型”和“视频流”这两个词。没有，2MB 有戏；有，把目标放宽到 8MB 到 15MB 更务实，别再跟 2MB 死磕了。

2. 动手前的准备：功能清单、基线测量与工具链

2.1 用需求倒推最小模块集

我最怕听到的需求是“就是做点图像处理”。这句话等于没说。必须逼着自己或者产品方把功能拆到函数级别：要不要读文件、读什么格式、要不要写文件、像素格式是什么、尺寸多大、做几路、实时性要求多少毫秒。把这些列清楚之后，模块对应关系几乎是自动浮现的。缩放、阈值、Canny、形态学、颜色空间转换、直方图，全部落在 imgproc。矩阵运算、ROI 切割、内存管理落在 core。读图写图落在 imgcodecs。

按照我的经验，一个典型的工业视觉预处理流程，九成情况下只需要core,imgproc；如果输入是 JPEG 或者 PNG 文件而不是裸数据，再加一个imgcodecs。highgui几乎永远是第一个被砍掉的，因为它会把 GTK、Qt、Win32 UI 这些图形库全拉进来，而你完全可以用一个 imwrite 把中间结果写出来看，或者干脆在 PC 上调好参数再移植。这里我给一个可以直接抄的映射表：

2.2 建立体积基线：size、nm、bloaty 三件套

裁剪最忌讳盲改参数，改完不知道省了多少、省在哪。所以第一步一定是把基线打出来。静态库阶段用size -A看各段大小，尤其关注.text、.rodata、.eh_frame、.debug_*；可执行文件阶段用size和nm --size-sort -C排出最大的符号，一眼就能看出是哪个模块在吃空间。如果条件允许，装个 bloaty 会更直观，它能按编译单元、按符号、按段三个维度给你出报告。

我习惯的第一个命令是nm --size-sort -C app | tail -30，它会把可执行文件里最大的三十个符号按升序列出来，正好是你要看的。很多次我以为 imgproc 是大头，结果排下来发现是 libjpeg 的解码表和 OpenCV 的 HAL 分派表。基线不清楚，后面每一步都是瞎猜。

# 静态库各段大小 size -A build-arm/lib/libopencv_imgproc.a | tail -5 # 可执行文件最大符号排行 nm --size-sort -C app | tail -30 # 按编译单元和符号细分（需要安装 bloaty） bloaty -d compileunits,symbols app # 查看 ELF 各段占用 arm-linux-gnueabihf-size --format=sysv app

2.3 交叉编译工具链与构建环境确认

裁剪参数改多了，很容易出现“PC 上编得过、板子上跑不起来”的情况，根因八成是工具链和系统库不一致。所以交叉编译一定要用一份明确的 toolchain file，不要靠环境变量临时拼。我常用的模板长这样，关键是CMAKE_FIND_ROOT_PATH那一组设置，它决定了 CMake 去哪找头文件和库，写错了会误用宿主机上的 x86 版本，编出来的东西在你板子上直接 Illegal instruction。

set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_C_COMPILER arm-linux-gnueabihf-gcc) set(CMAKE_CXX_COMPILER arm-linux-gnueabihf-g++) set(CMAKE_FIND_ROOT_PATH /opt/arm-sysroot) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

还有一件事提前确认好：板子上的 glibc 版本和你工具链的版本要对得上，尤其是你打算动态链接 libc 的时候。如果你想彻底摆脱依赖，可以走全静态-static，但那会让最终体积再涨几百 KB，因为 libstdc++ 和 libc 的静态版本本身就不小。我的建议是：根文件系统里本来就有的库就动态链，其余全部静态，两头的好处都占。

3. 实操：从CMake配置到最终二进制的完整流程

3.1 最小CMake配置清单

这是我最常用的一套配置，针对 ARM 32 位平台，只保留三个模块，只开 JPEG 解码。这张命令我基本是复制粘贴改改路径就用，里面每一个 OFF 都是有针对性的，下面我逐段解释。整条命令建议存成一个 shell 脚本，不然下次改参数很容易漏掉某一项。

cmake -S opencv-4.8.0 -B build-arm \ -DCMAKE_TOOLCHAIN_FILE=$PWD/toolchain-arm.cmake \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=/opt/opencv-min \ -DBUILD_LIST=core,imgproc,imgcodecs \ -DBUILD_SHARED_LIBS=OFF \ -DBUILD_opencv_apps=OFF -DBUILD_TESTS=OFF \ -DBUILD_PERF_TESTS=OFF -DBUILD_EXAMPLES=OFF -DBUILD_DOCS=OFF \ -DBUILD_JAVA=OFF -DBUILD_opencv_python2=OFF -DBUILD_opencv_python3=OFF \ -DWITH_IPP=OFF -DWITH_ITT=OFF -DWITH_OPENCL=OFF \ -DWITH_TBB=OFF -DWITH_OPENMP=OFF -DWITH_PTHREADS_PF=OFF \ -DWITH_EIGEN=OFF -DWITH_LAPACK=OFF -DWITH_PROTOBUF=OFF -DWITH_ADE=OFF \ -DWITH_QUIRC=OFF -DWITH_FREETYPE=OFF -DWITH_HARFBUZZ=OFF \ -DWITH_GTK=OFF -DWITH_QT=OFF -DWITH_WIN32UI=OFF \ -DWITH_FFMPEG=OFF -DWITH_GSTREAMER=OFF -DWITH_V4L=OFF -DWITH_1394=OFF \ -DWITH_JPEG=ON -DWITH_PNG=OFF -DWITH_TIFF=OFF -DWITH_WEBP=OFF \ -DWITH_OPENJPEG=OFF -DWITH_JASPER=OFF -DWITH_OPENEXR=OFF \ -DWITH_IMGCODEC_HDR=OFF -DWITH_IMGCODEC_SUNRASTER=OFF \ -DWITH_IMGCODEC_PXM=OFF -DWITH_IMGCODEC_PFM=OFF \ -DCPU_BASELINE=NEON -DCPU_DISPATCH= \ -DENABLE_PRECOMPILED_HEADERS=OFF \ -DCMAKE_C_FLAGS="-Os -ffunction-sections -fdata-sections -fvisibility=hidden" \ -DCMAKE_CXX_FLAGS="-Os -ffunction-sections -fdata-sections -fvisibility=hidden -fvisibility-inlines-hidden -fno-asynchronous-unwind-tables" \ -DCMAKE_EXE_LINKER_FLAGS="-Wl,--gc-sections -Wl,--exclude-libs,ALL"

BUILD_LIST是总闸门，它决定了哪些模块参与编译，这里省下来的体积是最大的一笔。后面那一长串WITH_*是关掉各种加速后端和第三方依赖，其中WITH_IPP和WITH_OPENCL在 x86 上尤其重要，IPP 的静态库单个就有好几兆。WITH_PROTOBUF和WITH_ADE是给 dnn 和 G-API 用的，既然模块都砍了，这两个也要显式关掉，否则 CMake 还是会尝试去找它们，找不到就报错。图像编解码那边，把 TIFF、WebP、OpenEXR、Jasper 全关掉，只留 JPEG，PNG 看你实际输入，如果板子上传的就是 JPEG，那 PNG 也一起关，连带的那份 zlib 也就省了。

3.2 编译期瘦身参数的取舍

-Os和-O2的差别在于，-Os会主动选择尺寸更小的指令序列，比如用循环代替展开、用函数调用代替内联。在图像处理这种热点循环密集的代码里，-Os带来的性能损失通常在 5% 到 15%，换来的是 15% 到 25% 的体积下降，这个交换比在空间受限场景下非常划算。我自己做了个简单基准：一张 1080p 图的 resize 加阈值处理，-O2需要 8.2ms，-Os需要 9.5ms，差距完全在可接受范围。

-ffunction-sections -fdata-sections配合链接期的--gc-sections，能把没被引用的函数和数据整段删掉。这一对在 OpenCV 上效果参差不齐，因为 OpenCV 内部有不少静态注册表和全局初始化代码，会把人意想不到的函数“钉”住，但整体还是能省个几十到几百 KB。-fvisibility=hidden是把所有符号默认设为隐藏，只导出显式标记的，这样链接器才知道哪些符号外部真的用不到，是--gc-sections生效的前提。

CPU_DISPATCH置空这一项，我要单独强调。OpenCV 默认会做运行时分派，同一份 resize 会编出 SSE2、AVX2 等好几个版本，在固定硬件的嵌入式设备上完全没必要。把它置空、只保留CPU_BASELINE=NEON，imgproc 的体积能直接掉三成。代价是失去了运行时自适应，但对单一硬件平台来说，这个代价等于零。构建完成后可以在 CMake 输出里确认一下，看到DISPATCH: []才算真的生效。

3.3 链接期与后处理：section GC、ICF、strip

编译完只是上半场，链接期的参数同样关键。-Wl,--gc-sections是配套-ffunction-sections的，不开这个前面白做。-Wl,--exclude-libs,ALL的作用是把静态库里那些本不该暴露的符号从动态符号表里去掉，对最终可执行文件的体积影响不大，但对可读性和启动速度有好处。-Wl,-O1让链接器自己做一轮符号优化，通常也能抠掉一点。

如果你的工具链里有 lld 或者 gold，强烈建议试试-fuse-ld=lld -Wl,--icf=all。ICF 是 identical code folding，它会把机器码完全相同的函数合并成一份，OpenCV 里同一套模板被不同精度、不同通道数实例化出来的函数，很多机器码是一致的，合并之后我实测过省了 50KB 上下。别小看这几十 KB，在 2MB 这个量级上，每一个 KB 都是挤出来的。

# 编译库 cmake --build build-arm -j$(nproc) cmake --install build-arm # 链接自己的应用，注意静态库顺序：依赖者在先 arm-linux-gnueabihf-g++ -Os -flto -ffunction-sections -fdata-sections \ -fuse-ld=lld -Wl,--icf=all -Wl,--gc-sections -Wl,--exclude-libs,ALL \ main.cpp -o app \ /opt/opencv-min/lib/libopencv_imgcodecs.a \ /opt/opencv-min/lib/libopencv_imgproc.a \ /opt/opencv-min/lib/libopencv_core.a \ -ljpeg -lpthread -lrt -ldl -latomic -static # 最后一步瘦身 arm-linux-gnueabihf-strip --strip-all app

这里有一个细节必须提：静态库的链接顺序是被依赖者写在后面。imgcodecs 依赖 imgproc，imgproc 依赖 core，所以顺序必须是 imgcodecs、imgproc、core，写反了会出现一大堆 undefined reference。-latomic是给 ARM 上的原子操作准备的，缺了它经常在链接阶段报__atomic_fetch_add_4未定义。LTO 想真正生效，最好在构建 OpenCV 的时候就带上-flto编译参数，否则只有你自己的 main.cpp 参与跨模块优化，收益有限。

3.4 实测体积变化对照表

下面这组数据来自我在 ARM Cortex-A7、GCC 9.4、OpenCV 4.8.0 上的一次完整记录，功能就是读 JPEG、缩放、阈值、输出 JPEG。数字仅供参考，但每一步的降幅比例是有代表性的。

从 38MB 到 1.8MB，缩到原来的百分之五不到。这里面贡献最大的是第二步，砍模块一步就干掉了七成以上，所以如果你时间紧，只做第二步也足够应付大部分场景。后面四步是精雕细琢，加起来又省了三倍多，属于“既然都改了，就顺手改到位”。

4. 要冲进2Mb以内，还得动这几处

4.1 imgcodecs：用轻量解码库换掉重依赖

imgcodecs本身代码量不大，真正占地方的是它背后的解码库。libjpeg-turbo 编译出来大概 200KB 到 400KB，libpng 加 zlib 大概 150KB 左右，TIFF 和 WebP 各自也在一两百 KB。如果你的输入格式很单一，比如就是设备端相机输出的 JPEG，那么完全可以考虑不用imgcodecs，直接上 stb_image 这个单头文件库，解 JPEG、PNG、BMP 都在行，用-Os编出来大概 60KB 到 120KB，比 libjpeg-turbo 小一半以上。

代价也要说清楚。stb_image 的解码速度比 libjpeg-turbo 慢，因为它没有 SIMD 优化，一张 2000×2000 的 JPEG 差个十几毫秒很正常；而且它默认不支持渐进式 JPEG 的错误恢复，遇到损坏文件的行为不如 libjpeg-turbo 稳健。如果板子上对解码耗时敏感，那就老老实实留着 libjpeg-turbo，只是编译时把用不到的部分关掉：共享库关掉、SIMD 按需开、turbojpeg 那个额外的 API 层关掉，能省下小几十 KB。

还有一种情况值得考虑：如果设备的图像来自传感器或者 FPGA，经过你自己的驱动直接拿到的是裸数据或者 YUV，那就别编imgcodecs了，自己在应用层写几十行把 YUV 转成 BGR 塞进cv::Mat，省掉整个解码库链。这种写法在嵌入式相机项目里非常常见，也是我见过的最干净的一种裁剪。

4.2 highgui与videoio：直接砍掉，自己接

highgui是我见过最容易被冤枉的一个模块。很多人只是想在调试的时候 imshow 看一眼，结果为了这个imshow把 GTK、Cairo、GDK、Pango、HarfBuzz 一整条链全拉进来了。这几样东西加起来动不动就是十几兆。正确的做法是：算法在 PC 上用完整版 OpenCV 调试，参数定下来之后，移植到板子上的版本里一行 imshow 都不留，中间结果用 imwrite 落盘，或者直接写/dev/fb0，再或者通过 socket 传到 PC 上看。

顺带说一个热词里经常出现的现象：waitKey()不带参数时程序卡住不动。这正是 highgui 那套事件循环的锅——它会一直等键盘事件，而很多嵌入式环境下根本没有输入设备，于是就一直阻塞在那儿。你把它砍掉之后，这类问题自然消失。所以砍 highgui 不只是为了瘦身，它同时消掉了一整类莫名其妙的卡死问题。

videoio是另一个大头，它会把 FFmpeg、GStreamer、V4L2 这些后端全拉进来。如果你只是想在 Linux 上从 USB 摄像头抓帧，自己写一百多行 V4L2 的 ioctl 就够了：开设备、设格式、申请缓冲区、mmap、入队出队。我之前做过一个对比，用 videoio 的版本单个可执行文件 4.8MB，换成自己写的 V4L2 抓帧加上 core 和 imgproc，掉到 2.1MB。省下来的都是 FFmpeg 那一大坨。

4.3 共享库加符号导出的另一条路

如果你的板子上不止一个程序要用 OpenCV，把库编成静态再分别链进去，等于每个可执行文件里都有份拷贝，总体积反而大。这种情况应该编成.so，然后靠符号可见性控制把导出的符号压到最小。做法是编译期加-fvisibility=hidden -fvisibility-inlines-hidden，同时在 CMake 里设-DCMAKE_CXX_VISIBILITY_PRESET=hidden、-DCMAKE_C_VISIBILITY_PRESET=hidden，让 OpenCV 的导出宏自己决定哪些符号对外可见。

这么做的效果是，共享库文件本身可能还有 2MB 到 3MB，但被--gc-sections清掉的内部符号更多，而且多个程序共享同一份内存映射，整体算下来更划算。还有一个好处是升级方便：算法更新了只要换一个.so，不用把所有程序重新链一遍。代价是多了一层动态链接开销，启动时多几毫秒，以及部署时别忘了带上这个库。我的经验是：单程序、追求极限体积，走静态；多程序、追求可维护性，走动态并做符号裁剪。

5. 踩坑实录与问题速查

5.1 编译与链接阶段的典型报错

第一个高频坑是 CMake 配置阶段报找不到 ZLIB。这个出现在你开了 PNG 但是系统里没有 zlib 开发包的时候。两个办法：装开发包装上，或者加-DBUILD_ZLIB=ON让 OpenCV 用自己打包的版本。前者更省事，后者更可控，我一般选前者。类似的还有 OpenEXR、Jasper 这些，都是你忘了关，CMake 又找不到对应依赖导致的。

第二个坑是链接阶段成片的undefined reference to cv::Mat::xxx。这九成是静态库顺序写错了，或者忘了把 core 排在最后。还有一种可能是你只链了 imgcodecs 却没链 imgproc，而 imgcodecs 内部调用了 imgproc 里的东西。排查方法很简单，把顺序按依赖关系倒过来排一遍，一般都能解决。

第三个坑是 ARM 上常见的原子操作符号缺失，报__atomic_load_8或者__atomic_fetch_add_4未定义。这是链接时缺-latomic，加上就好。第四个坑是用-fno-rtti之后某些版本编不过，因为 OpenCV 内部有地方用了dynamic_cast。我现在的做法是根本不开-fno-rtti，省的体积有限，风险却很大。还有一个容易踩的：开了-fno-exceptions之后编译报一大堆错误，这是意料之中的，因为 OpenCV 的CV_Assert就是抛异常实现的，别硬来。

5.2 运行期才暴露的坑

strip 之后最直接的副作用是崩溃时看不到有用的调用栈。板子上跑起来一旦崩了，日志里只有一串地址，根本不知道是哪儿挂的。我的习惯是永远保留一份没有 strip 的版本，出问题时用 addr2line 反查，定位完了再用 strip 版本上线。这个习惯帮我省过很多时间，尤其是在现场调试、没法重新编译的时候。

另一个坑是 imread 返回空 Mat。原因很可能是你只编了 JPEG，结果送进来一张 PNG 或 WebP，imgcodecs里根本没有对应解码器，它不会报错，只是默默返回一个空矩阵，然后你在后面.at()的时候才崩。所以解码后一定要判空，并且在应用层明确约定输入格式，别指望库帮你兼容一切。

性能方面的坑也值得一提。关掉CPU_DISPATCH之后，算法内部没有运行时 SIMD 分派了，resize这类函数的耗时可能比完整版慢两到三成。如果你的场景对性能敏感，可以只对 imgproc 保留分派，其他模块关掉，这样能兼顾一部分速度。还有就是-flto会让链接时间明显变长，在 CI 环境里如果构建超时，可以把 LTO 从 OpenCV 库构建里去掉，只在自己的应用链接时开。

5.3 问题速查表

6. 什么情况下别硬压

6.1 需要推理、检测、特征匹配的场景

有些需求从一开始就不该往 2MB 上凑。只要用到 dnn，protobuf 就被拉进来了，光这一项就是一两兆起步，再加上各种算子实现，十兆都算少的。人脸检测、行人检测走 objdetect 的 Haar 或者 DNN 路径，模型文件本身又要几兆，加起来更没法看。特征点匹配走 features2d，ORB 还算轻，SIFT 那套金字塔结构代码量不小，一般落在 4MB 到 7MB 这个区间。

判断的方法很直接：拿一份最小可用的功能样例，在 PC 上用完整版 OpenCV 跑通，然后用 bloaty 看一眼符号表，把最大的二十个符号找出来，看看它们属于哪个模块。如果最大的几个符号集中在 dnn 或者 features2d，那基本可以判断这条路走不通，直接跟需求方谈，把目标放宽到 8MB 或 12MB，比硬压到最后功能阉割掉一半要健康得多。

6.2 自研替代的临界点

还有个更彻底的选项：不用 OpenCV。如果你的需求就只是 resize、灰度化、阈值、颜色转换这几样，自己写两百行 C 代码是完全可行的，编出来三十 KB 不到，还没有任何依赖。我做过一次对比，一个只做双线性缩放加二值化的场景，OpenCV 精简版 1.8MB，自研版 28KB，性能还因为少了间接调用而更快一点。

但自研有明确的代价。第一是边界条件，各种尺寸的奇偶、通道对齐、越界处理，你都要自己过一遍，测试量不小。第二是后续扩展，今天只要缩放，明天要个形态学，后天要个直方图均衡，自研版本很快会变成一个小型 OpenCV，维护成本反而更高。所以我的经验分界线是：功能固定、最多三五个操作、没有扩展预期，那就自研；功能有演化空间、算法还会不断加，那就老老实实用裁剪过的 OpenCV，用成熟语义换取团队的开发效率。

最后再分享一个小技巧。裁剪的时候，建议把每一组参数和对应的体积记在一个表格里，就像上面那张对照表一样，同时把编译日期和 OpenCV 版本也记上。我吃过这个亏：某次升级到新版本之后体积突然涨了 400KB，翻记录才发现是新版本默认开了一个新的 SIMD 后端。有记录就能五分钟定位，没记录就得从头再排查一遍。裁剪这件事本身不难，难的是把变量控制住，让每次改动都有据可依。