没有开箱即用的“xml转pdf在线工具”能可靠处理发票，因为xml是数据结构而非格式，pdf是成品而非容器；必须通过解析xml、套用模板、渲染pdf三步链路实现。
直接说结论：没有开箱即用的“XML转PDF在线工具”能可靠处理发票——因为XML不是格式，是结构；PDF不是容器，是成品。你真正需要的是“解析XML + 套用发票模板 + 渲染为PDF”的三步链路。
为什么浏览器打开XML文件不等于能转PDF
XML文件本身不含样式、布局、字体或分页逻辑。invoice.xml 可能只有一堆 <amount>129.99</amount>，但PDF里这笔金额得出现在右下角、加粗、带千分位、和税额对齐——这些信息XML里根本没有。
常见错误现象：
• 把XML拖进Chrome，截图再转PDF → 字体错乱、无页眉页脚、打印缩放失真
• 用“XML to PDF converter”在线工具上传 → 转出的PDF全是扁平化标签文本，像 <total>129.99</total> 直接印在纸上
关键点：
• 所有靠谱的转换，都依赖一个中间层：XSL-FO、CSS（通过Paged Media）、或模板引擎（如Jinja/Handlebars）
• 在线工具若没声明支持你用的发票XML Schema（比如中国cnfa、欧盟UBL Invoice），基本不可信
最轻量可行方案：用xsltproc + fop本地跑（Linux/macOS）
这是税务系统、电子发票平台实际在用的链路，稳定、可审计、不传数据到第三方服务器。
实操建议：
• 先确认你的XML是否带<?xml-stylesheet type="text/xsl" href="invoice.xsl"?> ——如果有，说明已有配套XSLT，直接用xsltproc生成invoice.fo
• 没有XSLT？别手写。去GitHub搜 UBL Invoice xslt 或 cnfa pdf xslt，找已验证的开源转换器
• fop（Apache FOP）把.fo转PDF，命令极简：fop invoice.fo invoice.pdf
• 注意：fop不支持CSS Grid/Flex，中文需预装simhei.ttf并配置fop.xconf指定字体路径
开发中快速验证：用playwright渲染HTML再转PDF
适合已有发票HTML模板，或能用JavaScript解析XML生成DOM的场景——比XSLT学习成本低，调试直观。
使用场景：
• 后端Node.js服务需动态生成PDF发票
• 前端临时导出（注意：浏览器端XML转PDF会暴露敏感字段，生产禁用）
要点：
• 用DOMParser解析invoice.xml，提取document.querySelector('total').textContent等值
• 填入带@page CSS的HTML模板（必须含size: A4; margin: 20mm）
• playwright启动Chromium，page.pdf({ format: 'A4' }) ——它比window.print()更可控，支持header/footer
• 避坑：XML里可能有<这种双重转义，用new DOMParser().parseFromString(xmlStr, 'text/xml')才安全
在线工具到底能不能用？看这三点就清楚
如果你非要用在线服务（比如客户强要求），只看三个硬指标：
• 是否明确列出支持的XML标准？例如：UBL 2.1、CII、Factur-X —— 写“支持XML”=无效声明
• 是否允许上传XSLT或CSS文件？不能传，说明它只是把XML当纯文本暴力渲染
• 导出PDF后检查元数据：pdfinfo invoice.pdf | grep "Creator" —— 若显示libxml2或unknown，基本是裸解析，勿用于正式开票
复杂点在于：同一份invoice.xml，在中国要符合国家税务总局OFD+XML规范，在德国要嵌入EN16931校验码，在线工具几乎从不提这些。
