App端图片转base64必须用uni.canvasToTempFilePath：先createCanvasContext绘制，再canvasToTempFilePath导出临时文件，最后readFile读取二进制转base64；PDF生成禁用jspdf+html2canvas，推荐服务端Puppeteer或插件市场pdfmake；第三方库需无DOM/Node.js依赖；字体图标须用本地路径或base64。
App端图片转base64必须用 uni.canvasToTempFilePath，不能用浏览器API
uni-app的App端逻辑层运行在独立JS引擎（不是WebView里的浏览器），所以canvas.toDataURL()、FileReader等Web API直接报错或返回空字符串。真机调试时看到undefined或not implemented基本就是这个原因。
正确路径是：先用uni.createCanvasContext绘制内容 → 调用uni.canvasToTempFilePath导出临时文件 → 再用uni.getFileSystemManager().readFile读取二进制并转base64。
-
uni.canvasToTempFilePath在iOS和Android上行为一致，但quality参数只在App端生效（小程序端忽略） - 若需高分辨率截图，务必设置
width/height与canvas实际像素匹配，否则模糊 - H5端可用
toDataURL兜底，但App端必须走uni原生能力链路
PDF生成不要硬套jspdf + html2canvas
在App端直接引入jspdf和html2canvas npm包，90%概率白屏或崩溃——这两个库严重依赖DOM和CSSOM，而App端渲染层（webview）的DOM环境不完整，getComputedStyle、offsetHeight等常返回0或NaN。
可行方案只有两个：
- 用
renderjs节点执行html2canvas（仅限H5+App，微信小程序不支持renderjs）；注意allowTaint: true和useCORS: true必须同时开，否则图片空白 - 更稳的做法是走服务端：前端传HTML结构或数据，后端用Puppeteer/WeasyPrint生成PDF再下发base64或URL
- 插件市场已有成熟方案：
pdfmake兼容版插件，封装了App/H5/小程序三端PDF生成逻辑，避免自己踩canvas尺寸计算、分页、字体嵌入等坑
第三方npm库在App端能用的前提是「无DOM依赖」
很多开发者装完lodash、dayjs就以为万事大吉，结果在App端调用_.debounce时发现内存暴涨——问题不在函数本身，而在某些npm包的默认构建产物里混入了Node.js Polyfill（如process.nextTick），而uni-app App端JS引擎不支持。
验证方式很简单：在App端console里直接执行require('lodash')，不报错且返回对象才真正可用。
- 纯逻辑类库（
qs、uuid、ajv）大概率安全 - 带
fs、path、Buffer、XMLHttpRequest引用的，基本不可用 - 所有含
document、window、CSSStyleSheet访问的，App端必然失败 - 实在要用，优先查插件市场同功能插件，比如
moment不如用插件市场的uni-dateformat
字体、图标等静态资源必须走base64或本地路径，禁用CDN外链
App端打包后所有资源都在本地沙盒内，@font-face里写url(https://xxx.com/iconfont.woff)会因HTTPS证书校验失败或跨域被拦截，表现为图标不显示、字体fallback成系统默认。
正确做法只有两种：
- 把字体文件（.woff/.ttf）放
static/font/下，@font-face中用相对路径：url('/static/font/iconfont.woff') - 转成base64内联（适合小图标字体），用在线工具转换后直接写进
@font-face的src里，避免额外请求 - iconfont项目下载后，务必删掉
iconfont.css里所有url('//at.alicdn.com')的远程引用，只保留本地woff2/woff/ttf格式声明
这些路径规则在H5端也生效，但App端更严格——连http://本地服务器地址都不认，只接受/开头的绝对路径或static/下的相对路径。
