尧图网页设计 
HarmonyOS 7把async认对了Worker错误码也变了别再靠constructor.name决定调用方式升级后同一段Worker调用从序列化错误变成“方法不可调用或属于async”。如果错误处理只识别旧码新错误可能被当成临时失败反复重试。真正变化的是类型判定修正不是远程接口突然支持了异步方法。HarmonyOS 7修复了类中getter/setter之后定义的async方法被识别成普通Function的问题。State经过编译也可能生成访问器所以看似没有手写getter的页面同样值得检查。本文从本地命令分发和Worker调用白名单两个方向处理避免把运行时名称当成业务协议。依据官方Beta1变更说明页面更新于2026年8月19日9月28日复核。本文本地分发器和错误分类断言在宿主执行没有在本机重现旧ArkTS编译缺陷也没有执行API26 Worker设备调用。先读懂修复的范围官方说明指出在访问器之后定义的async方法变更前isAsyncFunction可能返回falseconstructor.name可能是Function变更后分别为true和AsyncFunction。原方法的异步行为不是本次才出现修复的是类型识别。相关起始API为8此项在官方汇总中属于全部生效。定位时应查util.types().isAsyncFunction和constructor.name的使用点而不是仅搜索新增API26代码。可在目标环境准备一个最小类import { util } from kit.ArkTS; class MethodOrderCheck { private value: number 1; async beforeAccessor(): Promisenumber { return 1; } get id(): number { return this.value; } set id(next: number) { this.value next; } async afterAccessor(): Promisenumber { return 2; } } const model new MethodOrderCheck(); const types new util.types(); console.info(before types.isAsyncFunction(model.beforeAccessor)); console.info(after types.isAsyncFunction(model.afterAccessor));应在不同目标环境分别保存结果不能把Node.js对这段类的正常识别当成旧ArkTS缺陷的复现。还要调用方法确认返回行为避免只看名称就推导业务结果。案例一本地命令分发不需要猜函数名字有的插件分发器先检查constructor.name认为AsyncFunction才需要等待。这个判断本身就不完整普通函数也可能返回Promise。修复类型识别只能纠正一部分输入不能让这种分发协议变可靠。对于应用自己管理的本地命令可以统一等待结果并把业务失败放到同一出口。下面刻意包含同步值、async方法和普通函数返回Promise三种情况。type Command () number | Promisenumber; type Result {ok:true;value:number}|{ok:false;message:string}; async function execute(command:Command): PromiseResult { try { const value await command(); if (!Number.isFinite(value)) return {ok:false,message:invalid result}; return {ok:true,value}; } catch (error) { return {ok:false,message:error instanceof Error ? error.message : unknown failure}; } } function eq(actual:unknown,expected:unknown): void { if (JSON.stringify(actual)!JSON.stringify(expected)) throw new Error(assertion failed); } eq(await execute(()3),{ok:true,value:3}); eq(await execute(async()4),{ok:true,value:4}); eq(await execute(()Promise.resolve(5)),{ok:true,value:5}); eq(await execute((){throw new Error(sync failed);}),{ok:false,message:sync failed}); eq(await execute(()Promise.reject(new Error(async failed))),{ok:false,message:async failed}); eq(await execute(()NaN),{ok:false,message:invalid result});这是本地调用不涉及跨线程序列化。统一await可以归一化结果却不会把CPU密集计算自动移到后台也不会让阻塞同步函数变得不阻塞。耗时工作仍应按实际并发方案设计。另外await一个永不完成的Promise仍会等待。需要超时时应加业务超时和取消设计但“超时返回”也不等于底层工作已取消。不要把类型问题修复后又引入执行生命周期误解。案例二Worker错误码变了调用能力没有放宽对于callGlobalCallObjectMethod调用这类async方法官方给出的错误变化是旧码10200006序列化异常新码10200020方法不可调用或属于async/generator。后者不是成功信号也不是要求原地重试的信号。错误10200006本身可能来自其它序列化问题不能全局解释成async10200020也不只代表async。建议错误分类保留范围再结合调用目标判断。function classifyWorkerError(code:number): serialization|not-callable-or-unsupported-kind|other { if (code 10200006) return serialization; if (code 10200020) return not-callable-or-unsupported-kind; return other; } type Endpoint { name:string; execution:sync|async; remoteAllowed:boolean }; function mayUseGlobalCall(endpoint:Endpoint): boolean { return endpoint.execution sync endpoint.remoteAllowed; } eq(classifyWorkerError(10200006),serialization); eq(classifyWorkerError(10200020),not-callable-or-unsupported-kind); eq(classifyWorkerError(1),other); eq(mayUseGlobalCall({name:readCache,execution:sync,remoteAllowed:true}),true); eq(mayUseGlobalCall({name:loadRemote,execution:async,remoteAllowed:true}),false); eq(mayUseGlobalCall({name:internalOnly,execution:sync,remoteAllowed:false}),false);这个白名单是应用约束不是平台能力检测。声明为sync的方法必须真的符合协议并检查参数与返回值可序列化。不能把async方法套一层普通函数再登记为sync那只是把Promise藏起来远程约束并没有消失。需要异步请求与响应时应选择支持该模式的消息协议带请求ID、成功失败响应与生命周期管理。本文不提供未经当前接口文档验证的Worker整套封装这里要解决的是阻止错误调用和错误重试而不是发明新远程接口。哪些判断保留哪些判断移走isAsyncFunction可以用于诊断与测试帮助看清类型识别变化。但业务分发如果能够通过显式元数据表达能力就不应靠constructor.name猜执行合同。名称可能受运行环境和构建过程影响而且“普通函数返回Promise”从来不需要async关键字。目的推荐判断不足本地取得最终结果await返回值统一错误出口不负责后台执行与取消判断远程入口是否允许明确白名单与执行契约声明仍需测试和审查定位类型识别变化官方类型检查加最小类不等同于调用能力测试处理Worker失败精确错误类别与目标记录不能看到未知码就自动重试回归时至少覆盖这几个顺序同一个类里放访问器之前和之后的async方法再加入普通函数返回Promise、同步抛错和异步拒绝。对页面类还要检查State相关声明后的方法。分别记录类型检查、实际返回、分发结果不要只截一行constructor.name。Worker侧则确认两个错误码都进入可解释的失败提示不触发无限重试修复调用协议后再测试正常路径。日志保留方法业务名和错误码即可不要把完整业务参数或敏感返回值全部打印出来。这条版本变化提醒我们运行时识别修正后旧代码可能走到从未走过的分支。真正耐用的修复是让执行协议显式、返回值处理一致而不是继续围绕一个字符串补更多例外。官方来源API26 Beta1针对所有应用的变更async函数类型判定修复行为变更汇总 HarmonyOS 7把async认对了，Worker错误码也变了：别再靠constructor.name决定调用方式
HarmonyOS 7把async认对了Worker错误码也变了别再靠constructor.name决定调用方式升级后同一段Worker调用从序列化错误变成“方法不可调用或属于async”。如果错误处理只识别旧码新错误可能被当成临时失败反复重试。真正变化的是类型判定修正不是远程接口突然支持了异步方法。HarmonyOS 7修复了类中getter/setter之后定义的async方法被识别成普通Function的问题。State经过编译也可能生成访问器所以看似没有手写getter的页面同样值得检查。本文从本地命令分发和Worker调用白名单两个方向处理避免把运行时名称当成业务协议。依据官方Beta1变更说明页面更新于2026年8月19日9月28日复核。本文本地分发器和错误分类断言在宿主执行没有在本机重现旧ArkTS编译缺陷也没有执行API26 Worker设备调用。先读懂修复的范围官方说明指出在访问器之后定义的async方法变更前isAsyncFunction可能返回falseconstructor.name可能是Function变更后分别为true和AsyncFunction。原方法的异步行为不是本次才出现修复的是类型识别。相关起始API为8此项在官方汇总中属于全部生效。定位时应查util.types().isAsyncFunction和constructor.name的使用点而不是仅搜索新增API26代码。可在目标环境准备一个最小类import { util } from kit.ArkTS; class MethodOrderCheck { private value: number 1; async beforeAccessor(): Promisenumber { return 1; } get id(): number { return this.value; } set id(next: number) { this.value next; } async afterAccessor(): Promisenumber { return 2; } } const model new MethodOrderCheck(); const types new util.types(); console.info(before types.isAsyncFunction(model.beforeAccessor)); console.info(after types.isAsyncFunction(model.afterAccessor));应在不同目标环境分别保存结果不能把Node.js对这段类的正常识别当成旧ArkTS缺陷的复现。还要调用方法确认返回行为避免只看名称就推导业务结果。案例一本地命令分发不需要猜函数名字有的插件分发器先检查constructor.name认为AsyncFunction才需要等待。这个判断本身就不完整普通函数也可能返回Promise。修复类型识别只能纠正一部分输入不能让这种分发协议变可靠。对于应用自己管理的本地命令可以统一等待结果并把业务失败放到同一出口。下面刻意包含同步值、async方法和普通函数返回Promise三种情况。type Command () number | Promisenumber; type Result {ok:true;value:number}|{ok:false;message:string}; async function execute(command:Command): PromiseResult { try { const value await command(); if (!Number.isFinite(value)) return {ok:false,message:invalid result}; return {ok:true,value}; } catch (error) { return {ok:false,message:error instanceof Error ? error.message : unknown failure}; } } function eq(actual:unknown,expected:unknown): void { if (JSON.stringify(actual)!JSON.stringify(expected)) throw new Error(assertion failed); } eq(await execute(()3),{ok:true,value:3}); eq(await execute(async()4),{ok:true,value:4}); eq(await execute(()Promise.resolve(5)),{ok:true,value:5}); eq(await execute((){throw new Error(sync failed);}),{ok:false,message:sync failed}); eq(await execute(()Promise.reject(new Error(async failed))),{ok:false,message:async failed}); eq(await execute(()NaN),{ok:false,message:invalid result});这是本地调用不涉及跨线程序列化。统一await可以归一化结果却不会把CPU密集计算自动移到后台也不会让阻塞同步函数变得不阻塞。耗时工作仍应按实际并发方案设计。另外await一个永不完成的Promise仍会等待。需要超时时应加业务超时和取消设计但“超时返回”也不等于底层工作已取消。不要把类型问题修复后又引入执行生命周期误解。案例二Worker错误码变了调用能力没有放宽对于callGlobalCallObjectMethod调用这类async方法官方给出的错误变化是旧码10200006序列化异常新码10200020方法不可调用或属于async/generator。后者不是成功信号也不是要求原地重试的信号。错误10200006本身可能来自其它序列化问题不能全局解释成async10200020也不只代表async。建议错误分类保留范围再结合调用目标判断。function classifyWorkerError(code:number): serialization|not-callable-or-unsupported-kind|other { if (code 10200006) return serialization; if (code 10200020) return not-callable-or-unsupported-kind; return other; } type Endpoint { name:string; execution:sync|async; remoteAllowed:boolean }; function mayUseGlobalCall(endpoint:Endpoint): boolean { return endpoint.execution sync endpoint.remoteAllowed; } eq(classifyWorkerError(10200006),serialization); eq(classifyWorkerError(10200020),not-callable-or-unsupported-kind); eq(classifyWorkerError(1),other); eq(mayUseGlobalCall({name:readCache,execution:sync,remoteAllowed:true}),true); eq(mayUseGlobalCall({name:loadRemote,execution:async,remoteAllowed:true}),false); eq(mayUseGlobalCall({name:internalOnly,execution:sync,remoteAllowed:false}),false);这个白名单是应用约束不是平台能力检测。声明为sync的方法必须真的符合协议并检查参数与返回值可序列化。不能把async方法套一层普通函数再登记为sync那只是把Promise藏起来远程约束并没有消失。需要异步请求与响应时应选择支持该模式的消息协议带请求ID、成功失败响应与生命周期管理。本文不提供未经当前接口文档验证的Worker整套封装这里要解决的是阻止错误调用和错误重试而不是发明新远程接口。哪些判断保留哪些判断移走isAsyncFunction可以用于诊断与测试帮助看清类型识别变化。但业务分发如果能够通过显式元数据表达能力就不应靠constructor.name猜执行合同。名称可能受运行环境和构建过程影响而且“普通函数返回Promise”从来不需要async关键字。目的推荐判断不足本地取得最终结果await返回值统一错误出口不负责后台执行与取消判断远程入口是否允许明确白名单与执行契约声明仍需测试和审查定位类型识别变化官方类型检查加最小类不等同于调用能力测试处理Worker失败精确错误类别与目标记录不能看到未知码就自动重试回归时至少覆盖这几个顺序同一个类里放访问器之前和之后的async方法再加入普通函数返回Promise、同步抛错和异步拒绝。对页面类还要检查State相关声明后的方法。分别记录类型检查、实际返回、分发结果不要只截一行constructor.name。Worker侧则确认两个错误码都进入可解释的失败提示不触发无限重试修复调用协议后再测试正常路径。日志保留方法业务名和错误码即可不要把完整业务参数或敏感返回值全部打印出来。这条版本变化提醒我们运行时识别修正后旧代码可能走到从未走过的分支。真正耐用的修复是让执行协议显式、返回值处理一致而不是继续围绕一个字符串补更多例外。官方来源API26 Beta1针对所有应用的变更async函数类型判定修复行为变更汇总