ldd 显示 not found 是最直接的信号，表明系统缺失运行时共享库（如 libwebp.so.5），需用包管理器安装对应运行时库（如 Debian/Ubuntu 下执行 sudo apt-get install libwebp6），而非手动复制 .so 文件。
ldd 显示 not found 是最直接的信号
当你在 Debian/Ubuntu 上运行 cwebp 或其他依赖 C 库的命令失败，且 exec.Command 只返回 exit status 1 而无具体错误时，先别改 Go 代码。直接在终端执行：
ldd $(which cwebp) | grep -i "not found\|webp"如果看到类似
libwebp.so.5 => not found，说明问题出在系统级动态库缺失，不是 Go 的 PATH 或权限问题。
用包管理器装对应 -dev 或运行时库，别手动复制
不同发行版安装方式不同，但原则一致：用系统包管理器，而非下载 .so 文件手动丢进 /usr/lib。否则版本错位、符号不兼容、后续升级冲突全会冒出来。
- Debian/Ubuntu：
sudo apt-get install libwebp-dev（开发头文件 + 运行时库）或sudo apt-get install libwebp6（仅运行时，版本号需匹配 ldd 提示） - CentOS/RHEL：
sudo yum install libwebp-devel或sudo dnf install libwebp-devel - Alpine：
apk add libwebp（注意 Alpine 默认用 musl libc，glibc 生态工具可能不兼容）
装完再跑 ldd $(which cwebp)，确认那一行变成类似 libwebp.so.5 => /usr/lib/x86_64-linux-gnu/libwebp.so.5 (0x00007f...) 才算真正解决。
容器环境里必须显式安装，基础镜像不等于“开箱即用”
Docker 镜像如 golang:1.21 或 alpine:latest 只含 Go 工具链和极简系统库，cwebp 本身及其依赖（libwebp、libpng、libjpeg）全得自己加。
立即学习“go语言免费学习笔记（深入）”；
- 基于 Debian：
RUN apt-get update && apt-get install -y webp libwebp6 libpng16-16 libjpeg62-turbo
- 基于 Alpine：
RUN apk add --no-cache cwebp libwebp libpng jpeg-dev
- 避免用
CGO_ENABLED=0掩盖问题——它能绕过 cgo 编译，但无法让外部命令加载缺失的.so
LD_LIBRARY_PATH 不是万能解，慎用且勿硬编码
临时调试可设 LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH，但生产环境这么干等于埋雷：
- Go 程序调用
exec.Command时，该变量只对当前进程生效，子进程默认继承，但若被目标命令自身清空或覆盖就失效 - 不同用户、不同 shell 启动方式（systemd vs 手动 bash）下变量可能未加载
- 更可靠的做法是：用
ldconfig -n /path/to/your/libs临时注册，或把库路径写进/etc/ld.so.conf.d/myapp.conf再运行ldconfig
真正容易被忽略的是：同一份二进制在不同机器上行为不一致，往往不是代码问题，而是 ldd 输出里那些 “=> not found” 行，在开发机上恰好被其他软件顺带装上了，而生产机干净得只剩 shell。每次部署前，都该把它当 checklist 项跑一遍。
