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 沙盒路径写死 —— 这些细节比选哪种方案更决定成败。
