夜雨聆风2026年6月20日，一条英文帖在X上刷屏了。
@JafarNajafov 贴出了一段话，1400+赞，2100+收藏，8万+浏览。核心意思很简单——你每次用在线工具编辑PDF，你的合同、银行流水、护照扫描件，全都被传到了别人的服务器上。
"Adobe Acrobat is cooked. Someone built a free, open-source PDF editor that runs entirely on your own machine and never uploads a single file."
「Adobe Acrobat被干翻了。有人做了一个完全在你本机运行的免费开源PDF编辑器，一个文件都不上传。」
帖子里列了一串数字：50多种PDF工具、OCR识别、密码加水印加签名、REST API、Docker一键自托管。对比对象直指Adobe Acrobat Pro——每年239美元。而Stirling-PDF，零元，81k GitHub星标，2500万+下载。
▲ @JafarNajafov的引爆帖，1400+赞，宣称Stirling-PDF处理完文件"下一秒就删除"
几乎同一时间，中文、西班牙语的"平行帖"在X上同步出现，文案高度一致，配图略有不同。几天之内，围绕"本地PDF隐私"的讨论已经卷起了一波声浪。
直白点说，这帖戳到了所有人的痛处：我们每天随手打开的那些在线PDF工具，几乎每一个都在悄悄把你的文件传上云。
50+工具、一行Docker命令、文件不出你的机器
Stirling-PDF到底是什么？
它是一个开源的PDF处理平台。GitHub上84.6k星，7.4k fork，5000+提交，182个release。核心承诺就一条：文件在你的硬件上处理，不上传，不记录，不传到任何外部服务。
怎么用？三种方式：
- Docker自托管
：一行命令拉镜像，浏览器打开即用，文件只在你自己的机器/服务器上流转 - 桌面应用
：Windows/Mac/Linux原生安装包，双击打开，"Open with"集成到系统右键 - 纯JAR手动部署
：极客最爱，零额外依赖
▲ 84.6k星、7200+fork的开源仓库，"without sending documents to external services"是核心承诺
它能做什么？合并、拆分、压缩、旋转、裁剪、修复——这些是基操。进阶能力同样能打：PDF转Word/Excel/PPT/图片/HTML/Markdown，Tesseract本地OCR多语言识别，加解密和权限设置，元数据清理，永久涂黑，水印，手绘签名和图片签名，无代码pipeline批量处理，REST API覆盖几乎所有功能。
痛点精准。日常办公里，合同要合并、发票要压缩、扫描件要OCR、涉密文件要涂黑——每一个动作，用在线工具就意味着"先把文件送给第三方"。Stirling-PDF做的事情很简单：把"服务器"搬到你自己的机房、NAS、甚至笔记本上。
处理完即删除：一个承诺的技术细节
官方文档对隐私模型的描述直截了当。文件的生命周期只有三步：
上传（存进临时内存/短期tmp）→ 处理（PDFBox、LibreOffice、Tesseract全在本机跑）→ 清理（"处理后立即删除"）。
文档反复强调 "stateless"——无状态。「Nothing is stored, logged, or transmitted to external services」。不存，不记，不外传。
OCR也是一个容易被误解的点。有人说"OCR得连服务器"。实际上，Stirling用的是Tesseract本地引擎。语言包你自己下载，挂进Docker卷或放本地路径就行。100页中文扫描合同扔进去，识别全程不经过Google Vision、Azure或任何第三方API。
▲ 官方文档Benefits页，第一条就是Data Security，明确"本地文件处理+任务完成后自动删除"
再加上REST API——你可以写脚本批量处理文件夹里几百个PDF，不打开浏览器，不需要任何网页交互。配合Paperless-ngx这类文档归档工具，整个工作流全在内网完成，一个比特都不出网。
到这里，产品的逻辑是自洽的：你需要一个PDF工具箱，又不想把文件交给别人——Stirling-PDF给你一套方案，开源、本地、零外传。
问题出在后面。
2025年那场"自托管工具打电话回家"的风暴
2025年4月，GitHub上炸开了一个issue。
编号#3283，标题是"Tracking Pixel Sends Data Even When Users Opt Out"——即使用户选择退出，跟踪像素仍在发送数据。报告者的发现让人后背一凉：自托管的Docker实例，页面居然在加载Scarf跟踪像素（pixel.stirlingpdf.com），而且弹出了cookie同意横幅。
自托管工具，为什么会有第三方像素？
三个月后，r/selfhosted上的热帖把这个质疑推到了顶点（43赞，35评论）。原帖作者的语气几乎是愤怒的："我自己搭的服务，为什么还要弹cookie条？为什么在往外发数据？"
评论迅速分裂。一部分人说"只是开源项目的usage统计，PostHog也做了mask，没什么大不了的"。另一部分人的态度更坚决："自托管就该零遥测。默认应该关，不是事后拿个env变量让我配。"
信任这东西，建立起来要几年，碎掉只要一个issue。
有人直接建议用DNS改写、hosts屏蔽、甚至nginx sub_filter来硬封掉那个像素。一个"保护你隐私"的工具，用户反而要用技术手段来保护自己不受这个工具的监控——这个反讽太刺眼了。
▲ 质疑声音：有用户测试stirling.com/app/signup后指出"这分明是云"，暴露了托管版和自托管版之间的边界模糊
团队在v1.5.0（2025年10月）做了重构。统一开关、默认opt-in（需要明确同意才会启用）、新增DISABLE_PIXEL和SYSTEM_ENABLESCARF=false环境变量。专门开了一个文档页解释遥测的范围和控制方式。
▲ Analytics文档页，详细说明了Scarf/PostHog的范围、控制方式和关闭方法
现在的情况是：你完全可以关掉所有遥测——设一个环境变量，或者air-gapped环境下直接断开。Scarf只收集部署类型和版本号，不存IP，不碰PDF内容。PostHog做了元素mask，服务器在EU。
但问题是，有几个普通用户会去读这份文档？
和Adobe的真实差距：不是谁打败谁
功能层面，做一个诚实的对比：
Stirling-PDF对"80%用户的80%PDF需求"做得很好。拆分合同、扫描件OCR、批量水印、简单合并、压缩——免费、够快、本地跑。如果你是律师、医生、创业者、处理政府文件的公务员，单是"文件不出机器"这一点就值回所有折腾成本。
Adobe在另外20%上的护城河仍然很深。精确的文本布局编辑、复杂表单填写、专业预印检查、合格电子签名（eIDAS QES级别）——这些不是开源社区短期内能追平的。
尤其是电子签名。视觉签名（画个字或贴张图）在很多场景下够用，但一旦涉及法庭、银行、政府，就需要密码学签名加受监管的证书链。欧洲的eIDAS标准、美国的审计要求，都绑定在中心化信任提供者（CA、QTSP）上。开源项目天然很难在这个领域建立同等的法律认可。
▲ Grok的平衡评价：隐私和本地优势巨大，但Adobe在精确编辑、复杂表单、专业印刷上仍领先
Grok在原帖下的回复说得很到位：对大多数处理敏感文档的人，Stirling-PDF优秀且省钱；power user仍然需要结合使用。
数据主权：你的文件，谁说了算
回到最根本的问题。
你上一次在线"合并两个PDF"的时候，有没有想过那份文件被传到了哪里？有没有想过它是否被留存、被分析、被用于训练模型、或者因为一纸传票被交出去？
Stirling-PDF代表的趋势，远不止一个PDF工具。它是"本地优先、隐私优先"这一波开源运动的典型样本。不只是PDF——图像压缩、视频剪辑、AI文档总结、云笔记附件处理——每一个"先上传再处理"的场景，都存在同样的风险。
自托管的核心价值在哪？攻击面控制在你自己手里。你能看到日志，能断网测试，能审计代码，能关掉任何你不想要的功能。
代价也实在：你得会Docker，得读文档，得记得更新，偶尔还得修配置。对愿意折腾的人，这是自由。对不想折腾的人，这是门槛。
Stirling-PDF的故事不是"开源打败Adobe"的爽文。它是一个关于选择的提醒：当你想处理一份涉密文件时，你有权决定它经过谁的服务器。那个81k星的开源项目，就摆在那里——用不用在你，但它至少让你知道，存在另一个选项。
"Every time you edit a PDF online, your file gets uploaded to someone else's server. Your NDA. Your bank statement. Your scanned passport."
「每次在线编辑PDF，你的文件都被上传到了别人的服务器。你的保密协议。你的银行流水。你的护照扫描件。」