uni.opendocument 在真机上常失败，根本原因是未处理平台差异和临时文件生命周期；必须用 downloadfile → savefile → opendocument 链路，ios需escape编码中文路径，h5须改用office web viewer或iframe内嵌。
直接用 uni.openDocument 在真机上大概率失败——安卓报“file not found”、iOS 弹“无法打开”、H5 完全没反应。根本原因不是 API 不能用，而是没处理平台差异和临时文件生命周期。
uni.downloadFile + uni.openDocument 为什么总是失败
这是最常踩的坑：以为下载完就能直接打开，结果各端都报错。
-
uni.downloadFile返回的tempFilePath是沙盒内临时路径，系统文档查看器默认无权访问 - 安卓可能在
openDocument前就清理了该临时文件；华为/小米等厂商限制更严 - iOS 沙盒隔离强，
tempFilePath不在Document目录，uni.openDocument拒绝授权 - H5 端压根不生成本地路径，
tempFilePath是空字符串，saveFile和openDocument全部失效
必须走 downloadFile → saveFile → openDocument 链路
uni.saveFile 才是关键转折点：它把临时文件持久化到应用私有目录（如 _doc/），返回的 savedFilePath 才是各平台都认可的打开入口。
- 必须等
saveFile.success回调拿到savedFilePath后再调uni.openDocument，不能只监听downloadFile.success - iOS 上若文件名含中文或特殊字符（如“报告_2026.pdf”），需用
escape()编码，否则openDocument静默失败 - 安卓 10+（API 29+）即使申请了存储权限，也不建议写入公共目录（如
/sdcard/），优先用_doc/或_downloads/
示例片段：
uni.downloadFile({
url: 'https://example.com/report.pdf',
success: (res) => {
if (res.statusCode === 200) {
uni.saveFile({
tempFilePath: res.tempFilePath,
success: (saveRes) => {
const filePath = saveRes.savedFilePath;
const platform = uni.getSystemInfoSync().platform;
const finalPath = platform === 'ios' ? escape(filePath) : filePath;
uni.openDocument({
filePath: finalPath,
showMenu: true
});
},
fail: console.error
});
}
}
});
H5 环境必须单独跳转，不能复用 App 逻辑
H5 下 uni.downloadFile 实际触发浏览器原生下载，tempFilePath 为空，uni.saveFile 和 uni.openDocument 全部不可用。此时唯一可行方案是跳转微软 Office Web Viewer 或浏览器内置 PDF 查看器。
Cn Password Generator
下载
安全的随机密码生成器。支持自定义长度、字符类型（大写/小写字母、数字、特殊符号），排除相似字符，批量生成。纯 Python 标准库，无需 API 密钥。
- PDF / Word / Excel：用
https://view.officeapps.live.com/op/view.aspx?src=+encodeURIComponent(url) - 注意 URL 必须公网可访问，且扩展名要规范（如
.docx，非.doc） - 单文件建议 ≤10MB，超大会加载超时或白屏
- 不要用
window.open新窗口，改用<iframe></iframe>内嵌可避免跳出当前页
例如：
const docUrl = `https://view.officeapps.live.com/op/view.aspx?src=${encodeURIComponent('https://example.com/report.docx')}`;
// 插入 iframe 或跳转
document.getElementById('viewer').src = docUrl;
文件类型识别不能只靠后缀名
用户上传的文件可能改名、无后缀、或 MIME 类型与扩展名不符。光靠 file.name.split('.').pop() 会误判，尤其在微信小程序里后端返回的 Content-Type 更可靠。
- 优先检查响应头中的
Content-Type（如application/vnd.openxmlformats-officedocument.wordprocessingml.document） - 后备才用扩展名映射，且要覆盖新版格式（
docx/xlsx/pptx） - 对未知类型，别硬塞
fileType参数——uni.openDocument会自动识别，传错反而失败
比如后端返回 Content-Type: application/pdf，就别管它叫 report.txt，直接当 PDF 处理。
最容易被忽略的是 iOS 中文路径编码和 H5 的完全异构逻辑——这两个点一旦漏掉，90% 的“预览失败”问题就出在这儿。
