uniCloud.uploadFile 必须用本地临时路径（如 tempFilePath）和带后缀的 cloudPath；云函数无法中转上传客户端图片；成功后只存 fileID，删除必须走云函数。
uniCloud.uploadFile 能直接传，但必须注意 filePath 和 cloudPath 的来源
前端调用 unicloud.uploadfile 是最常用的方式，但它不是万能的——filepath 必须是本地临时路径（比如 uni.chooseimage 或 chooseavatar 返回的 tempfilepath），不能是网络地址或 base64 字符串；cloudpath 是云存储里的目标路径，必须带后缀（如 "user/avatar/123.jpg"），否则上传会失败且无明确报错。
常见错误现象：uploadFile:fail invalid file path，基本就是 filePath 已过期（临时路径 30 秒失效）或根本不是合法路径；cloudPath 缺少扩展名时，部分服务商（如腾讯云）会静默拒绝，返回空 fileID。
- 上传前务必检查
tempFilePath是否存在、是否为字符串类型 -
cloudPath建议由前端生成，格式统一为"${type}/${timestamp}-${Math.random().toString(36).substr(2, 8)}.${ext}" - 不要在
cloudPath中使用中文或空格，避免 CDN 解析异常
云函数里再调一次 uniCloud.uploadFile？没必要，反而容易出错
很多开发者看到文档里说“云函数也能调 uniCloud.uploadFile”，就想着把图片从客户端先发到云函数，再由云函数中转上传。这是典型误解：云函数没有访问客户端临时文件的能力，tempFilePath 只存在于用户设备上，传到云函数里只剩一个无效字符串。
真正需要云函数介入的场景，是上传前做校验或改写——比如限制图片尺寸、检测违规内容、重命名、生成缩略图。这时应该让客户端直传，云函数只处理元数据或回调逻辑。
- 客户端直传更高效，绕过中间转发，节省云函数执行时间与流量
- 若需鉴黄，用
uniCloud.contentSecurity.imageModeration，传入的是已上传成功的fileID，不是原始文件 - 云函数内调
uniCloud.uploadFile仅适用于服务端生成的文件（如 canvas 绘制图、PDF 合成），不适用于用户选择的图片
上传成功后，fileID 是唯一可用地址，别存 imageUrl 字段
上传成功返回的 res.fileID 就是图片的最终可访问地址，形如 "cloud://my-space-123456789/user/avatar/abc.jpg"。这个值可以直接赋给 <image></image> 标签的 src，无需拼接域名或 CDN 地址——uniCloud 会自动解析并走最优节点。
很多人习惯在数据库里建一个 imageUrl 字段存完整 URL，这不仅冗余，还埋下隐患：一旦服务空间迁移或域名变更，所有历史记录都要批量更新。
- 数据库只存
fileID（字符串）、originalName、size、createTime等必要字段 - 前端展示时直接用
fileID，uni-app 内部已适配各平台渲染逻辑 - 如果要做防盗链或权限控制，用云存储的「访问规则」配置，而不是靠改 URL
删除图片必须走云函数，前端无法直接删云存储文件
这是最容易被忽略的兼容性差异：阿里云版 uniCloud **禁止前端直接删除**云存储文件，必须通过云函数调用 uniCloud.deleteFile；而腾讯云版允许前端调用，但官方仍建议统一走云函数——因为删除操作必须和数据库记录同步，否则必然出现“图还在但数据没了”或“数据删了但图占着空间”的不一致。
错误做法：前端拿到 fileID 后直接调 uniCloud.deleteFile({fileID})，在阿里云环境下会报 permission denied。
- 封装一个
deleteImage云函数，接收fileID和对应数据库_id - 云函数内先调
uniCloud.deleteFile，成功后再删数据库记录 - 加个 try-catch，失败时回滚或打日志，避免“删一半”状态
整个流程里最脆弱的一环其实是临时路径生命周期和 fileID 的使用方式——它不难，但错一点就会卡住半天。别迷信“自动上传”，每个路径、每个字段、每次调用，都得亲手确认来源和用途。
