stirling-pdf

核心用法

Stirling-PDF Skill 是一个 Node.js 封装的命令行工具，通过 REST API 与自托管的 Stirling-PDF 服务交互，实现 PDF 的全方位处理。用户需先部署 Stirling-PDF 实例（Docker 或本地），配置 STIRLING_PDF_URL 和 STIRLING_API_KEY 环境变量后，即可通过 node pdf.js <operation>> 执行操作。支持合并、拆分、旋转、OCR、压缩、格式转换、水印、签名、密码保护等 20+ 种功能，同时提供直接 curl 调用方式供高级用户使用。

显著优点

隐私优先的自托管架构：所有 PDF 处理在本地服务器完成，敏感文档无需上传第三方云端，满足企业合规要求。功能全面：覆盖日常办公所需的全部 PDF 操作，从基础页面管理到专业 OCR、红章、数字签名一应俱全。零依赖设计：脚本仅使用 Node.js 内置模块，无 NPM 第三方依赖，彻底规避供应链攻击风险。开源可信：底层 Stirling-PDF 是 GitHub 20k+ stars 的活跃开源项目，代码完全透明可审计。灵活部署：支持 Docker 一键部署，也可集成到现有基础设施，API 设计符合 REST 规范，易于自动化集成。

潜在缺点与局限性

部署门槛：需要用户自行部署和维护 Stirling-PDF 服务，对技术小白不够友好。功能边界：作为客户端封装器，实际处理能力受限于后端服务版本，部分高级功能可能需要特定配置。性能瓶颈：大文件处理依赖本地服务器资源，高并发场景需自行扩容。协议风险：默认使用 HTTP 连接，生产环境需手动配置 HTTPS 才能保障传输安全。无图形界面：纯命令行工具，非技术用户学习成本较高。

适合的目标群体

企业 IT 管理员：需要在内网环境处理敏感 PDF，满足数据不出域的合规要求。开发者与运维工程师：需要将 PDF 处理集成到自动化工作流、CI/CD 管道或内部系统。隐私敏感的个人用户：不愿将简历、合同等私人文件上传至在线 PDF 工具。文档密集型行业：法律、金融、医疗、教育等领域有大量批量 PDF 处理需求。

使用风险

传输安全：默认 HTTP 配置存在中间人攻击风险，务必在生产环境启用 HTTPS。API Key 管理：密钥通过 HTTP 头传输，泄露后可能导致未授权访问。输入文件风险：脚本不对 PDF 内容进行安全扫描，恶意构造的文件可能利用后端漏洞。服务可用性：依赖自托管服务的稳定性，单点故障会导致功能完全不可用。curl 依赖：系统必须预装 curl，部分精简环境可能需要额外安装。

核心用法

Stirling-PDF Skill 是 Stirling-PDF 自托管平台的命令行封装工具，通过 Node.js 脚本调用 REST API 实现 PDF 批量处理。用户需先部署 Stirling-PDF 实例（Docker 或原生部署），配置 STIRLING_PDF_URL 和 STIRLING_API_KEY 环境变量后即可使用。

典型工作流：

# 合并多个 PDF
node pdf.js merge file1.pdf file2.pdf -o merged.pdf

# OCR 识别扫描件
node pdf.js ocr scanned.pdf -o searchable.pdf

# 压缩文件体积
node pdf.js compress input.pdf -o compressed.pdf

# 格式互转
node pdf.js pdf-to-word input.pdf -o output.docx

核心功能矩阵：

| 类别 | 操作 |

|------|------|

| 页面操作 | merge, split, rotate, extract-pages, reorder |

| 格式转换 | convert-to-pdf, pdf-to-word, pdf-to-image, pdf-to-text |

| 内容处理 | compress, ocr, add-watermark, redact, sign |

| 安全保护 | add-password, remove-password, sanitize |

---

显著优点

1. 功能全面：覆盖 60+ 种 PDF 操作，相当于开源版 Adobe Acrobat Pro
2. 自托管隐私：数据不上传第三方云端，适合敏感文档处理
3. 零依赖设计：仅使用 Node.js 内置模块（fs/path/child_process），无 npm 依赖树风险
4. API 透明：直接暴露 Stirling-PDF REST API，高级用户可绕过封装脚本直接调用
5. 跨格式支持：LibreOffice 集成实现 Office ↔ PDF 双向转换

---

潜在局限

1. 基础设施依赖：必须自行部署维护 Stirling-PDF 服务（建议 2GB+ 内存）
2. 子进程架构：使用 curl 子进程而非原生 HTTP 模块，Windows 需预装 curl
3. 无请求超时：当前实现未设置 --max-time，大文件可能挂起
4. T3 社区维护：非官方背书，更新频率依赖个人开发者
5. OCR 质量受限：依赖 Tesseract，复杂排版识别准确率低于商业方案

---

适合人群

• 隐私敏感型企业：法律、医疗、金融等需本地处理机密 PDF
• 开发者/DevOps：已有 Docker 基础设施，需要自动化 PDF 流水线
• 开源替代寻求者：不愿支付 Adobe/ABBYY 许可费用的团队
• 技术熟练用户：能理解 REST API 和自托管运维

---

常规风险

| 风险项 | 说明 | 缓解措施 |

|--------|------|----------|

| 自托管可用性 | 服务宕机则 Skill 不可用 | 配置健康检查与自动重启 |

| 网络暴露 | 若公网部署需认证 | 务必设置 `STIRLING_API_KEY` |

| 大文件处理 | 内存/超时问题 | 分块处理或增加服务器资源 |

| curl 注入 | 当前实现参数可控，风险低 | 避免修改脚本接收任意 shell 参数 |

安全认证评分 S级（85分），代码结构清晰，无高危漏洞，适合生产环境谨慎部署。