unidoc/unipdf 合并 pdf 报“license not set”因未设置许可证，默认仅支持处理最多3页pdf，超出即panic；需申请免费开发许可并用license.newlicensefrombytes加载。
用 unidoc/unipdf 合并 PDF 文件时为什么报错 “license not set”？
不设置许可证，unidoc/unipdf 默认只允许处理最多 3 页的 PDF，超出就 panic 并提示 license not set。这不是 bug，是 SDK 的硬性限制。
实操建议：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 若用于内部工具或非商用场景，可申请免费开发许可（需邮箱注册），下载
pdf.license文件后，调用lic, _ := license.NewLicenseFromBytes(...)加载 - 跳过许可证的“临时方案”不可取——改源码、打补丁或用旧版 v2 分支都会导致功能缺失（如加密 PDF 无法读取、文字渲染异常）
- 注意：v3+ 版本已移除社区免费版，
github.com/unidoc/unipdf/v3/...路径下所有包都强制校验 license
用 pdfcpu 拆分 PDF 时如何按指定页码范围提取？
pdfcpu 命令行够用，但 Go 代码里调用得走它的 API 层，不是直接 exec。关键在 pdfcpu/pkg/api.ExtractPages 函数。
常见错误：传入页码字符串如 "1-3,5" 却没做预处理，导致 panic —— 它实际接收的是 []int 切片，不是字符串。
实操建议：
- 用
pdfcpu/pkg/pdfcpu.ParsePageSelection("1-3,5")先解析成页码列表，再传给ExtractPages - 拆分单页时别写
ParsePageSelection("2")，它返回[]int{2}没问题；但写"2-2"也行，结果一样 - 性能上，
pdfcpu是纯 Go 实现，无 CGO，适合容器环境；但对含大量图像/OCG 图层的 PDF，内存占用比unipdf高约 20%
合并多个 PDF 时如何保持原文件书签（outline）结构？
默认合并会丢弃所有 outline。只有 unidoc/unipdf 支持手动重建，pdfcpu 目前（v0.3.14）完全不支持 outline 合并。
实操建议：
- 用
unipdf/v3/model.PDFReader.ReadOutline()分别读取每个源 PDF 的 outline 节点 - 合并后调用
PDFWriter.AddOutlineEntry()逐个添加，注意更新每条目里的Dest.PageNum偏移量（因为页码已变） - 如果某 PDF 没 outline，
ReadOutline()返回 nil，不要 panic，跳过即可 - 书签层级超过 3 级时，部分阅读器（如 macOS 预览）可能折叠显示，这不是代码问题，是 PDF 规范兼容性限制
生产环境 PDF 处理必须检查的三个边界条件
很多本地测试通过的合并/拆分逻辑，一上生产就出错，往往卡在这三类情况：
- 输入文件为空或损坏：
os.Stat()后必须用pdfcpu.ValidateFile()或unipdf.NewReader()的 error 判断，不能只看文件大小 > 0 - 页码越界不报错反而静默截断：
pdfcpu.ExtractPages对"10-20"在只有 5 页的文件里会返回成功但输出空 PDF；务必提前用pdfcpu.GetNumPages()校验范围 - 中文路径或文件名乱码：Linux 容器里默认 locale 是 C，
os.Open("测试.pdf")可能失败；统一用filepath.FromSlash()+ UTF-8 路径，避免依赖系统编码
outline 重建和页码偏移修正最容易被跳过，但用户投诉“目录点不动”“跳转错页”基本都出在这里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
