uni-app无法在云端生成PDF，因其仅为前端框架，不支持服务端DOM/CSS/Canvas环境；html2canvas与jsPDF是纯前端库，依赖浏览器API，在Node.js云函数中会报document或Canvas未定义错误；真正可行的云端生成需由后端服务（如pdfmake、WeasyPrint）完成，uni-app仅负责传参、接收二进制流并调用uni.downloadFile和uni.openDocument处理。
uni-app 本身不能在云端生成 PDF 文档——它只是前端框架，不执行服务端逻辑。所谓“云端生成”，必须由后端服务完成，uni-app 只负责发起请求、接收结果、触发下载或预览。
为什么不能用 html2canvas + jsPDF 在云端生成
html2canvas 和 jsPDF 是纯前端库，运行在用户设备的 WebView 或浏览器中。它们依赖 DOM、Canvas API 和 JS 执行环境，这些在服务端（如 Node.js）默认不可用。即使你强行在云函数里跑 Puppeteer 渲染 HTML 再转 PDF，那也不是 uni-app 的能力，而是后端渲染服务的能力。
常见误解是把「H5 端能跑的代码」直接搬到云函数里，结果报 document is not defined 或 Canvas is not available —— 这类错误说明你混淆了执行环境。
- uni-app 的
onLoad、methods、renderjs全部运行在客户端 - 云函数（如阿里云 FC、腾讯云 SCF、DCloud uniCloud）运行的是 Node.js，没有 window/document/Canvas
- 若想“前端触发、云端生成”，必须拆成两步：uni-app 发送参数 → 后端服务接收并生成 → 返回 PDF 文件 URL 或 ArrayBuffer
可行的云端 PDF 生成链路（推荐方案）
真正可落地的“云端生成”，是指 uni-app 调用你自己的后端接口，由后端完成 PDF 构建并返回结果。典型路径如下：
- uni-app 收集要生成 PDF 的数据（如订单号、用户 ID、模板变量），用
uni.requestPOST 到你的服务端接口 - 后端用
pdfmake（Node.js）、weasyprint（Python）、itext7（Java）等服务端 PDF 库生成文件 - 后端将 PDF 存入对象存储（如 OSS、COS），返回一个带鉴权的临时 URL；或直接以
arraybuffer形式返回二进制流（注意设置responseType: 'arraybuffer'） - uni-app 接收后，走标准 PDF 下载+打开流程：
uni.downloadFile→ 检查statusCode === 200→uni.openDocument或plus.runtime.openFile
示例关键片段（uni-app 端）：
uni.request({
url: 'https://your-api.com/generate-pdf',
method: 'POST',
data: { orderId: 'ORD123456', lang: 'zh-CN' },
responseType: 'arraybuffer',
success: async (res) => {
if (res.statusCode !== 200) return;
const fs = uni.getFileSystemManager();
const finalPath = `${uni.env.USER_DATA_PATH}/report_${Date.now()}.pdf`;
// 注意：arraybuffer 需先写入本地文件
fs.writeFile({
filePath: finalPath,
data: res.data,
encoding: 'binary',
success: () => {
uni.openDocument({ filePath: finalPath });
}
});
}
});
uniCloud 场景下特别注意的坑
如果你用的是 DCloud 官方 uniCloud，需明确以下限制：
-
uniCloud的云函数默认不支持canvas、jsdom等重型依赖，html2canvas直接不可用 - 不要尝试在云函数里
require('html2canvas')或new jsPDF()—— 这些包不是为服务端设计的 - 若坚持用 HTML 模板生成 PDF，uniCloud 可调用外部 Headless Chrome 服务（如通过 Puppeteer Serverless），但需自行部署维护，且冷启动延迟高
- 更轻量的做法：云函数只做数据组装和签名，把 PDF 生成委托给专用微服务（如用 FastAPI + WeasyPrint 部署的独立 endpoint）
真正容易被忽略的一点：**云端生成的 PDF 必须确保 Content-Type 是 application/pdf，且响应体是原始二进制流**。如果后端返回了 JSON 包裹的 base64 字符串，uni-app 就得额外做 base64 → ArrayBuffer 转换，而很多开发者卡在这步的编码处理上（比如漏掉 atob + Uint8Array 构造）。最稳的方式，是让后端直出二进制流，前端用 responseType: 'arraybuffer' 接收。
