queryRiskFactors 返回成功为什么还不能用：HarmonyOS 7 status 和 result 要分开解析-平芜编程栈

queryRiskFactors 返回成功为什么还不能用：HarmonyOS 7 status 和 result 要分开解析

queryRiskFactors 的每个风险因子同时包含 status 和字符串 result。status 表示该因子的查询是否成功，result 才承载具体值。只看总接口成功就把缺失项当安全，或直接用 Boolean(result)，都会出错：字符串“0”在 JavaScript 中也是真值。API 26 新增的能力必须建立按因子、按类型的解析表。

先把官方边界和项目策略分开

关注点	官方边界或工程判断	常见错误
调用额度	每应用每设备 5 次/分钟、20 次/天	页面每次出现都查询
返回结构	每个因子有 status 与字符串 result	只看外层成功码
nonce	16-66 字节并建议每次新生成	复用固定挑战

上表左侧是接口事实，中间同时包含官方边界与明确标注的工程判断，右侧是最容易造成线上误判的写法。接入前先确认系统能力与版本，再把调用放到统一服务里；不要让每个页面分别复制一套安全逻辑。

案例一：失败项保持 unknown，不自动变成安全

解析器先检查 status，再按因子类型解析 result。查询失败输出 unknown，让上层决定重试或降级；绝不能输出 false。下面用布尔型因子演示三态结果。

type FactorResult = { status: number; result: string }; type TriState = 'yes'|'no'|'unknown'; function parseBooleanFactor(input: FactorResult): TriState { if (input.status !== 0) return 'unknown'; if (input.result === '1' || input.result === 'true') return 'yes'; if (input.result === '0' || input.result === 'false') return 'no'; return 'unknown'; } if (parseBooleanFactor({ status: 0, result: '0' }) !== 'no') throw new Error('字符串 0 被误判'); if (parseBooleanFactor({ status: 9, result: '0' }) !== 'unknown') throw new Error('查询失败被当成安全');

第一段代码只验证外围决策模型。它不替代 Device Security Kit 的真实调用，也不包含生产密码学实现；价值在于让边界条件、重试和降级可以重复测试。

案例二：不同因子使用独立解析器

VPN、代理适合三态布尔，ODID 重置次数是非负整数，窗口模式和 HDC 是位掩码。用一套 parseInt 后转 Boolean 的通用逻辑会丢信息。注册表把因子名映射到解析器，未知因子原样进入待适配队列。

type Parsed = boolean|number|'unknown'; function parseFactor(name: string, value: string): Parsed { if (name === 'vpn' || name === 'proxy') return value === '1' ? true : value === '0' ? false : 'unknown'; if (name === 'odidResetCount') { const n = Number(value); return Number.isInteger(n) && n >= 0 ? n : 'unknown'; } return 'unknown'; } if (parseFactor('odidResetCount', '3') !== 3) throw new Error('计数因子解析错误'); if (parseFactor('futureFactor', '1') !== 'unknown') throw new Error('未知因子被擅自解释');

第二个案例覆盖另一类失败路径。接入系统接口时还要验证不支持、权限拒绝、网络超时、频控、前后台切换与进程恢复，不能只跑一次成功流程。

为什么选择这种做法

把所有字段强转布尔值代码最短，却会让“0”、计数和位掩码全部失真。因子注册表虽然多几行，但能显式处理版本新增字段，也更适合灰度和审计。

真正值得复用的不是某个页面回调，而是“输入事实 -> 安全信号 -> 分级决策 -> 可恢复反馈”这条链。页面只消费结果，服务层负责版本、频控、超时和脱敏，服务端负责挑战、验签与审计。

这类能力为什么容易接错

安全接口最危险的误区，是把一次返回值直接翻译成“允许”或“拒绝”。真实链路至少包含能力是否支持、调用是否成功、结果是否可信、结果是否仍在有效期、业务能否降级五层。任何一层缺失，都不应该把用户永久挡在门外。接口给的是安全信号，业务需要的是可解释、可恢复的决策。

建议把系统能力放在薄适配层里，业务层只接收普通对象。这样既能在宿主环境验证状态转换，也能在更换 SDK 或设备能力时集中修改。日志只保留请求编号、耗时、错误类别和脱敏后的策略结果，不记录 token、nonce、完整 JWS、网址参数、设备标识或用户内容。

怎样验证，哪些结论还不能提前说

下面代码中的纯 TypeScript 决策函数可以在宿主环境运行断言，用来证明分支、位掩码和状态转换没有自相矛盾。涉及 Device Security Kit、权限、传感器、网络、证书链和系统窗口的片段，仍需 API 26 SDK 编译，并在支持相应能力的 HarmonyOS 7 设备上验证。

当前本地环境只能验证外围模型，不能把它写成“已经完成 API 26 编译”或“真机实测通过”。正式验收至少记录 DevEco Studio 与 SDK 版本、设备系统版本、能力探测结果、正常与失败路径、频控表现、前后台恢复和降级提示。服务端验签还应保存证书链版本、验签失败类别和时钟偏差，但绝不落原始敏感凭证。

封装与复用建议

推荐统一输出四类结果：可信并放行、需要二次确认、暂时不可用可重试、不支持而降级。页面只负责展示和触发，不直接解析 JWS、位掩码或错误码。服务端策略要有版本号，客户端上报能力版本和匿名请求编号，方便灰度回滚。这样同一套安全边界可以复用到登录、支付、内容发布和企业管控，而不会把具体页面写死在系统接口里。