uni-app新版本HBuilder X打包后uni.uploadFile执行异常旧版本打包出来的正常使用

uni-app新版本HBuilder X打包后uni.uploadFile执行异常旧版本打包出来的正常使用

开发环境 版本号 项目创建方式
Windows Windows 11 HBuilderX

示例代码：

uni.uploadFile({  
    url: url,  
    name: 'file',  
    file: options.file,  
    header: header,  
    formData,  
    success: (res) => {  
        console.log(res, '上传图片成功数据');  
        const response = JSON.parse(res.data);  
        if ([402, 401].includes(response.code)) {  
            handleRequest(response, options).then((res) => {  
                resolve(res);  
            });  
        } else {  
            resolve(response);  
        }  
    },  
    fail: (err) => {  
        console.log(err, '上传图片失败数据');  
        reject(err);  
    }  
});

操作步骤：

  • 使用最新的HBuilderX（4.84/4.85）打包，去上传图片

预期结果：

  • 可以正常上传图片

实际结果：

  • 图片已经上传成功了，但是进入了fail逻辑，不能正常上传图片

bug描述：

  • uni.uploadFile方法在HBuilder X 4.60版本打包出来正常使用，使用最新的4.84以及4.85版本打包出来的包异常，一直进入的是fail，实际上接口已经上传成功，并返回了链接

更多关于uni-app新版本HBuilder X打包后uni.uploadFile执行异常旧版本打包出来的正常使用的实战教程也可以访问 https://www.itying.com/category-93-b0.html

6 回复

该bug反馈内容不完整，关键缺失目标平台信息（App/iOS/Android/Web/小程序类型）及fail回调中err的具体错误码和消息，难以精准复现。代码示例缺少服务器响应格式、header细节和错误处理逻辑，无法直接验证问题。
根据知识库，云打包机版本匹配规则可能导致行为差异：HBuilderX 4.85可能匹配到不同云端打包版本（如4.86），而4.60版本行为正常说明存在版本兼容性问题。uni.uploadFile在各平台兼容性表显示需注意响应解析逻辑变化，新版本可能更严格校验HTTP状态码或响应体格式。
实际结果中"接口已上传成功但触发fail"表明客户端对成功响应的判定条件变更，可能因：

服务器返回非2xx状态码（如304重定向）被新版本视为失败
响应体JSON格式异常（如包含BOM头、非法字符）
网络请求库底层实现变更

建议用户补充：

具体目标平台（App需区分iOS/Android/鸿蒙）
fail回调中err.errMsg和err.statusCode
服务器响应原始数据（headers+body）
尝试添加complete回调查看完整执行流程

参考云打包版本匹配规则，可尝试降级HBuilderX至4.80或升级至最新正式版验证。若为App平台，需检查manifest.json中权限配置是否完整。 内容为 AI 生成，仅供参考

更多关于uni-app新版本HBuilder X打包后uni.uploadFile执行异常旧版本打包出来的正常使用的实战教程也可以访问 https://www.itying.com/category-93-b0.html


目标平台：web（在安卓和iOS真机均可复现）
fail回调errror信息：{“errMsg”: “uploadFile:fail file error”} 错误信息
服务器响应原始数据： hearders access-control-allow-headers
x-requested-with,x-www-form-urlencoded,Authorization,token, content-type
access-control-allow-methods
POST, GET, OPTIONS, DELETE
access-control-allow-origin
*
access-control-max-age
3600
connection
keep-alive
content-length
145
content-type
application/json;charset=UTF-8
date
Wed, 10 Dec 2025 00:37:43 GMT
server
nginx/1.13.1
set-cookie
JSESSIONID=7C6E388A08720D9B18073245A93167D7; Path=/; HttpOnly body { “success”: true, “data”: “https://lbbtech.oss-cn-shenzhen.aliyuncs.com/globalSettings/picture/5398703220251210083743090.png”, “error”: “”, “code”: “0” }

检查一下 API 的入参，filePath 和 files 是不是都没有传，这两个参数不能同时为空

是都没有传，只传了file，是新的版本要求吗，之前代码都运行的好好，只有更新完HBUilderX之后才异常了（同事旧版本打包出来是正常，我更新了最新的HBUilderX就异常了）

回复 宸理: 修了一个bug，之前能运行是bug导致的，新版本修复了bug

根据你的描述，这很可能是新版本HBuilderX在打包时对uni.uploadFile的响应处理逻辑进行了调整，导致了一个兼容性问题。核心问题在于：接口实际上传成功（服务器已处理并返回了数据），但客户端的SDK错误地触发了fail回调，而非success回调。

问题分析与排查方向：

  1. 首要排查点：HTTP状态码

    • uni.uploadFile的success回调触发条件，除了网络请求成功到达服务器外，通常还要求HTTP响应状态码为200。
    • 请立即检查服务器接口的返回值。打开浏览器开发者工具（Network面板）或使用抓包工具，查看上传请求的HTTP Status Code。
    • 如果状态码不是200（例如204、205、3xx等），新版本的uni-app基础库可能将其判定为失败，从而进入fail回调。 即使响应体（res.data）里包含了成功的数据，success回调也不会被触发。

  2. 检查响应数据格式

    • 在fail回调中，将err对象完整打印出来（console.log(JSON.stringify(err))）。
    • 关注err.statusCode属性。如果它存在且值不是200，就印证了上述第1点的判断。
    • 同时，新版本可能对响应数据的格式有更严格的校验。请确认服务器返回的数据是标准的JSON格式，且没有BOM头等异常字符。

临时解决方案与验证：

  1. 修改代码，在fail回调中尝试解析数据： 这是最快的验证和临时解决方式。修改你的fail回调，尝试判断是否实际上是“成功的失败”。

    fail: (err) => {
    console.log('上传进入fail回调', err);
    // 尝试从err对象中获取服务器返回的数据
    if (err.statusCode === 200 || (err.data && err.data.indexOf('{') > -1)) {
        // 如果状态码是200，或者err.data中包含JSON字符串，则视为成功
        console.log('实际上传成功，数据在err中', err.data);
        try {
            const response = JSON.parse(err.data);
            // 在此处处理你的成功逻辑，例如调用resolve(response)
            resolve(response);
        } catch (e) {
            // 解析失败，确实是错误
            reject(err);
        }
    } else {
        // 其他情况，按真正的失败处理
        console.log('实际上传失败', err);
        reject(err);
    }
}
回到顶部