EasyInvoicePDF 是一个免费、开源、100% 在浏览器中运行的发票生成器，由开发者 Vlad Sazonau 创建。它的核心特点是无需注册、无广告、即时生成 PDF，所有数据均在本地处理，隐私性极强。
✨ 核心功能
- 即时 PDF 生成与实时预览：在输入发票信息的同时，右侧会实时更新 PDF 预览，一键即可下载。
- 多套可定制模板：内置默认模板和 Stripe 风格的现代化模板，支持上传 Logo 进行品牌定制。
- 智能税务计算：支持 VAT、GST、销售税及自定义税种，可自动计算金额，并支持自定义税种标签。
- 多语言与多币种：支持 10 种以上语言和 120 种以上货币，切换语言时税率标签和货币格式会自动更新。
- 二维码与多页支持：可为发票添加支付二维码（如支付链接、UPI 等），并自动处理多页 PDF 的分页。
- 卖家/买家信息保存：可保存常用信息，方便在后续发票中快速复用。
️ 技术栈
项目采用了现代前端开发的典型组合：
- React + TypeScript：构建组件化、类型安全的用户界面
- Next.js：提供生产级框架支持（如 SEO 优化、路由等）
- TailwindCSS + shadcn/ui + Origin UI：负责样式与 UI 组件
- @react-pdf/renderer：在客户端生成 PDF 文件
上传发票，等于免费泄露客户的银行账号！
不少在线发票工具：填好客户名称、税号、银行账户，下载 PDF 到电脑。你以为搞定了，但你填写的所有信息，都存在别人的服务器数据库里，等待下一次数据泄露。
EasyInvoicePDF，开源在线发票生成器，全程在浏览器本地运行，数据不上传服务器。 别以为只是普通的隐私宣传。它和别的工具根本不是一回事：没有后端处理你的发票数据，没有数据库保存客户信息，表单里输入的每一个字符，全程只留在你的浏览器内存。这是架构层面的不同，不是一个简单的隐私选项。
# 重写版：发票数据安全的两条路，和一家开源工具的选择
你的发票数据，最终流向哪里
在线填表、一键生成 PDF，不同工具的数据流向其实只有两条路。
绝大多数工具走的是服务器路线：你在页面填好内容，数据打包发给后端；服务器调用渲染引擎生成 PDF，再传回给你下载。整条链路里，客户姓名、地址、银行账号、交易金额——所有信息都在别人的服务器上停留过。停留多久、存在哪里、有没有加密、会不会被异地备份，你无从知晓，也无从验证。
EasyInvoicePDF 走的是另一条路。它用 @react-pdf/renderer 把发票的排版和渲染全部放在浏览器本地完成。你在表单里输入的内容，直接喂给浏览器内的 React 组件，组件渲染成 PDF 文档结构，再调用浏览器的下载功能存到本地。服务器在这个过程里只做一件事——在你首次打开网页时下发 JavaScript 代码。之后你输入的任何业务数据，与服务器再无关系。
打个比方：服务器路线，像你写好一封信交给陌生人，请他打印后还给你——他看过了内容，也留下了副本。浏览器路线，像你自己买了台打印机，信从头到尾都在你手里，打印完拿走，无人经手。
耐人寻味的是：同样是"在线发票生成器"，一个把你的财务数据送出设备，一个让数据一步都不离开电脑，可它们在搜索结果里并排出现，标签都写着"免费"。
一次数据库泄露，撕开的口子
你可能觉得：数据传上服务器能有多大风险，大公司总该有基本防护吧。
2025 年 10 月，安全研究员 Jeremiah Fowler 发现一个可公开访问的数据库，里面躺着 178,519 个文件，全部来自云端发票平台 Invoicely。客户姓名、公司信息、银行账号、交易记录，赤裸裸地暴露在互联网上，任何人找到那个 IP 就能直接下载。
这些数据能用来干什么？伪造发票、精准钓鱼，甚至冒充供应商向你的客户发催款通知。骗子手握你们之间完整的交易记录，发出的催款邮件几乎可以乱真。
但这不是说所有云端工具都会泄露。多数 SaaS 厂商的安全团队确实在认真做事。真正的问题，不在"会不会泄露"，而在"你有没有选择权"。
选了服务器路线的工具，你就把数据安全的主动权交给了别人：对方安全策略到位，你就安全一点；对方裁掉安全团队，你就裸奔。你无法验证，也无法控制。
浏览器端渲染的差别就在这里——你的数据从头到尾都在自己的设备上。没有中间商，没有服务器备份，没有可以被拖库的数据库。数据安全的边界，就是你电脑的安全边界。电脑被攻破，数据才会丢；电脑没事，数据就没事。这个逻辑简单到不需要信任任何人。
但事情没那么简单。浏览器端渲染，同样有代价。
没有服务器，代价是什么
最直接的代价是性能。@react-pdf/renderer 的打包体积比 jspdf 大不少，因为它依赖 React 的渲染抽象层。浏览器要下载更多 JavaScript、解析更多代码，才能开始工作。对只有几十行代码的简单 PDF，jspdf 可能更快。
但发票不是简单 PDF——它有表格、嵌套布局、自动分页、多语言和货币格式化。@react-pdf/renderer 让你用 JSX 写 PDF 布局，和写 React 组件一样。这种表达能力，在小工具上体现不出来，在复杂文档上就是刚需。
另一个代价是跨设备同步。数据存在浏览器本地存储，意味着你换台电脑，之前保存的卖家信息、买家档案就全没了。云端的 SaaS 工具让你在任何设备登录继续工作，浏览器端方案做不到——换个浏览器，都未必能读到同样的本地数据。
于是就有了一个真实的权衡：要便利，还是要控制权。
- 选云端：数据在别人的服务器上，任何设备随时访问，但数据已离开你的掌控。
- 选浏览器端：数据不离开你的设备，但换设备就得重新来过。
EasyInvoicePDF 选了后者，并用设计来补偿这个代价——保存卖家和买家档案，下次开票直接复用，减少重复输入。
浏览器端渲染还有一个更隐蔽的问题。
你信任的那个浏览器
浏览器端渲染的隐私承诺，建立在一个前提上：你的浏览器本身可信。但这个前提，未必总是成立。
浏览器扩展能读取页面内容，恶意扩展能抓取你输入的任何东西，无论数据有没有传给服务器。操作系统如果有键盘记录器，你在浏览器里敲的每一个字都会被捕获。就连浏览器的自动填充，都可能在你没注意时把数据同步进你的 Google 或 Apple 账号。
EasyInvoicePDF 保护的是你的数据不被它的服务器看到，但它没有、也不可能保护你的数据不被你自己设备上的其他东西看到。这条边界在哪里，取决于你的设备环境有多干净。
而这恰恰是它的优势所在。云端工具的数据泄露是系统性的：一个数据库被攻破，成千上万用户的发票数据同时暴露。你一个人再小心也没用，因为问题出在平台那一端。浏览器端方案的风险是个体化的：你的设备出问题，只影响你一个人。前者你无法控制，后者你至少可以控制。
那么，到底该怎么选？
从代码仓库里翻出的答案
EasyInvoicePDF 的 GitHub 仓库里有一个细节，决定了它和所有同类工具的根本区别——它的许可证是 AGPL v3。这不是随便选的。
AGPL 要求：任何基于它修改、并对外提供服务的版本，都必须公开源代码。也就是说，如果你把它改一改做成收费在线服务，你必须把修改也开源。你不能拿了开源社区的代码，改几行字，包装成闭源产品去卖。
这和 MIT 许可证是两种逻辑。MIT 允许拿代码商用，改完不用公开，想怎么卖怎么卖。很多号称"开源"的 SaaS 工具用 MIT，因为鼓励商业采用，甚至鼓励你把它变成闭源产品。AGPL 反其道而行：你可以用、可以改、可以自托管，但不能把它做成一个黑箱服务来收割用户。
作者 Vlad Sazonau 把可验证性放在商业友好性前面。数据不离开浏览器，是技术层面的承诺；代码在 GitHub 公开、任何人都能审计，是制度层面的承诺。两者加起来，构成一个完整的信任链：你不必信任作者，也不必信任服务器，只需要信任公开的代码。代码不会说谎，但人会选择怎么用代码。
发票的下一站
EasyInvoicePDF 最新版本是 v1.0.4，2026 年 9 月 4 日发布，主要改进 PDF 预览速度——发票只生成一次，桌面预览、移动端查看器和下载按钮共用同一份文件，消除了重复渲染的闪烁问题。这个优化看似技术性，背后却是同一个逻辑：减少不必要的计算，也减少数据在系统里流转的次数。每一次流转，都是一次暴露的风险。
项目目前有 742 颗星。这个数字不大，但它代表的是一群愿意花时间读源码、理解数据流向、然后做出选择的人——他们选择不把客户的银行账号交给一个看不见的数据库。
但这个选择有一个代价，仓库的说明文档里没有写清楚：如果你用共享电脑或公用浏览器打开 EasyInvoicePDF，你的卖家档案和买家信息会留在浏览器本地存储里。下一个人用这台电脑打开同一个网页，可能直接看到你上次填的客户信息。
浏览器端渲染保护了你的数据不被服务器看到，却没有保护它不被你身边的人看到。这个问题怎么解决，作者没说——文档里没有提，更新日志里也没有。你只能自己注意，或者等下一个版本。