uni-app如何实现App端的文件重命名 uni-app原生文件系统操作【代码】

uni-app App端无法直接重命名文件，必须通过uni.copyFile复制到新路径再uni.removeFile删除原文件实现；需注意路径合法性、权限申请及执行顺序，iOS建议用Documents或Cache路径，Android推荐使用uni.env.USER_DATA_PATH。

uni-app App端不能直接重命名文件

uni-app 的 uni.rename 在 App 端（iOS/Android）**不生效**，调用后既无报错也无效果，这是最常踩的坑。根本原因是：App 端底层未对接原生文件系统重命名能力，H5 和小程序端虽支持，但 App 端被静默忽略。

真正可行的路径只有一条：先 uni.copyFile 到新路径，再 uni.removeFile 原文件 —— 本质是「复制 + 删除」模拟重命名。

App端重命名必须用 copyFile + removeFile 组合

这是目前唯一稳定、全平台（含 iOS/Android）可用的方式。注意顺序不能反，否则可能丢失文件；也要确保目标路径可写（尤其 Android 需检查 WRITE_EXTERNAL_STORAGE 权限）。

• uni.copyFile 的 srcPath 必须是本地绝对路径（如 _www/xxx.jpg 或 file://...），相对路径会失败
• destPath 必须包含完整新文件名，且父目录需已存在（uni.getFileSystemManager().mkdir 可提前创建）
• 删除原文件前务必确认 copyFile 的 success 回调已触发，不要依赖 complete
• iOS 上若原路径在 tmp 目录，复制后立即删除可能因沙盒机制失败，建议统一用 Documents 或 Cache 路径

const fs = uni.getFileSystemManager();const oldPath = '_www/old.pdf';const newPath = '_www/new_renamed.pdf';fs.copyFile({  srcPath: oldPath,  destPath: newPath,  success: () => {    fs.removeFile({      filePath: oldPath,      success: () => console.log('重命名完成'),      fail: err => console.error('删除原文件失败', err)    });  },  fail: err => console.error('复制失败', err)});

Android 权限和路径兼容性问题

Android 10+（API 29+）默认启用分区存储（Scoped Storage），_www、Documents 等路径行为变化大，容易导致 copy 失败或文件不可见。

• 目标路径尽量用 uni.env.USER_DATA_PATH（对应 Application Documents Directory），它始终可读写且不受分区限制
• 避免硬编码 /storage/emulated/0/...，应通过 uni.getFileSystemManager().getSavedFileList 或 uni.getFileInfo 检查路径有效性
• Android 6.0+ 需动态申请 android.permission.WRITE_EXTERNAL_STORAGE（仅 targetSdk
• 调试时用 adb shell ls -l /data/data/包名/files/ 查看实际文件落点，比日志更可靠

为什么不用 plus.io 或 nativePlugin？

有人尝试用 plus.io（5+ Runtime 提供）或自定义原生插件调用 NSFileManager/File.renameTo，理论上可行，但实际落地成本高：

• plus.io 已被官方标记为「不推荐使用」，HBuilderX 新项目默认不启用，且 iOS 14+ 存在兼容风险
• 原生插件需分别维护 iOS/Android 两套逻辑，还要处理路径转换（如把 _www/xxx 映射到真实 bundle 路径）、异常捕获、Promise 包装
• 绝大多数业务场景下，copy + remove 的性能差异可忽略（小文件毫秒级，大文件本就不该在前端重命名）

真正卡住的往往不是技术上限，而是路径拼错、权限没弹、回调没等全、iOS 沙盒路径写死 —— 这些细节比选哪种方案更决定成败。