App端“指纹解压”实为两步独立操作：先调用uni.startSoterAuthentication完成跨平台生物认证，再手动触发UTS插件（如XF-zipUTS）解压；路径须用uni.env.USER_DATA_PATH，且三端方案需分离。
App端不能把“指纹识别”和“文件解压”串成一个功能链——它们是完全独立的系统能力，没有原生 API 支持“用指纹授权后自动解压”。所谓“指纹解压”，实际是两个动作：先做生物认证（指纹/面容），再在认证通过后执行解压逻辑。中间没有系统级绑定，全靠你手动编排。
uni.checkFaceID 和 uni.startSoterAuthentication 别混用
在 App 端，uni.checkFaceID 是 iOS 原生封装，Android 上基本不可用；而 uni.startSoterAuthentication 才是 uni-app 官方推荐的跨平台生物认证入口。真机调试时：uni.checkFaceID 在 Android 上大概率返回 {available: false, reason: "not supported"}，这不是 bug，是设计如此。
- 必须先调
uni.checkIsSupportSoterAuthentication确认设备支持fingerPrint - 再调
uni.checkIsSoterEnrolledInDevice({checkAuthMode: 'fingerPrint'})确认用户已录入指纹 -
challenge参数必须由服务端生成并下发，前端硬编码（如'123456'）会导致后端验签失败 - 认证成功后拿到的
result.encryptedData是加密凭证，不是解压触发信号——它只用于服务端身份核验
解压操作必须等认证完成后再手动发起
生物认证通过后，你得自己调用解压逻辑。App 端最稳的方案是用 UTS 插件，比如 XF-zipUTS 或 harmony-zip，它们直接调用原生 ZIP 库，不走 JS 解压，性能好、兼容强、支持密码保护。
-
unzip接口要求传入zipFilePath（本地绝对路径，如/data/user/0/xxx/files/xxx.zip）和destDirectory（目标目录，需提前mkdir） - H5 和小程序端无法使用这些 UTS 插件，
uni.getFileSystemManager().readFile读取的只是临时 ArrayBuffer，JSZip 解压大文件极易内存溢出 - 不要试图在
success回调里直接写uni.downloadFile→unzip链式调用，路径权限和异步时序容易错乱；建议分步：下载完存到uni.env.USER_DATA_PATH，再传给unzip
文件路径和权限是崩溃高发区
App 端文件系统不是“随便读写”的。iOS 沙盒路径、Android Scoped Storage、plus.io 的旧路径体系三者不互通，写错就 fail: no such file or directory。
- 下载后的 ZIP 文件路径要用
tempFilePath，但 UTS 插件不认这个；必须用uni.saveFile或writeFile存到可持久化路径（如uni.env.USER_DATA_PATH）后再传入 - Android 10+（targetSdkVersion ≥ 29）下，
plus.zip.decompress已失效，必须用 UTS 插件或 fflate + ArrayBuffer 分块处理 - iOS 上
uni.env.USER_DATA_PATH对应的是NSDocumentDirectory，可读写；但不能写到tmp目录，解压时会因路径不可访问失败
真正卡住人的从来不是“怎么写代码”，而是“哪个路径在哪种平台下能被哪个 API 正确识别”。生物认证只是个开关，解压才是重活——别指望一套代码横跨三端，App 端就老实用 UTS，H5 就走后端解压，该切就切。
