JSON 解析与 ArkTS 序列化一、引言JSON 是应用数据流转的事实标准服务端响应、本地缓存、组件 key 生成、调试日志输出都离不开它。在多设备短视频项目中JSON.stringify被大量用于列表 key 生成与日志输出而JSON.parse则是网络数据第 38 篇进入模型层第 36 篇的必经之路。但 JSON 与 ArkTS 的对象并不等价JSON 只有对象、数组、字符串、数字、布尔与 null 六种类型而 ArkTS 的 class 可以携带方法、联合类型字段与运行时资源引用。从 JSON 到类型安全的模型实例需要一套明确的转换规范。本文结合项目真实用法讲解JSON.parse/stringify基础、class 类型安全解析、复杂嵌套结构、ArkTS 序列化限制以及 mock/网络数据的转换路径。二、JSON.parse 与 JSON.stringify 基础两个 API 互为逆操作stringify把对象序列化为字符串parse把字符串还原为对象。项目中最常见的用法是作为列表 key 与日志输出// features/multishortvideoindividual/src/main/ets/view/Works.ets节选RepeatWorksDataModel(this.worksData).each((item:RepeatItemWorksDataModel){// ...GridItem 渲染}).key((item:WorksDataModel)JSON.stringify(item))// 用序列化结果做唯一 key// features/multishortvideoadaptivevideo/src/main/ets/view/AdaptiveAVPlayer.ets节选Logger.info(TAG,changePortraitVideo immersionInfo ${JSON.stringify(immersionInfo)});stringify的序列化规则值得牢记默认仅序列化可枚举的自身属性undefined、函数、Symbol 会被静默省略NaN与Infinity转为null数组中的null/undefined保留为null。这些规则决定了模型类只有数据字段第 36 篇规范是对象可稳定序列化的前提——一旦模型混入方法或资源对象序列化结果将不再可靠。三、class 与接口的类型安全解析JSON.parse返回类型是object | null实际语义接近any直接访问字段没有任何编译期保护。将 JSON 还原为 class 实例必须显式转换// 安全的反序列化JSON - AvDataSourceModelfunctionfromJson(json:string):AvDataSourceModel[]{constrawJSON.parse(json)asArray{currentSource?:string};returnraw.map((item)newAvDataSourceModel(item.currentSource??));}这里的关键不是强转而是逐字段校验as只欺骗编译器字段缺失时运行结果仍是undefined。对于服务端可能缺字段的数据应在构造函数层面兜底——项目模型构造函数中的??默认值如MSVDataModel的iconOnly ?? false正是为此设计。反例是直接JSON.parse(body) as CommentDataModel[]后取item.pic一旦服务端未返回该字段undefined就会泄漏到 UI 层引发渲染异常。规范总结为接口定义类型形状class 提供构造兜底两层配合实现类型安全。四、复杂嵌套结构的解析评论接口的响应是典型的嵌套结构外层是评论数组每条评论又含回复数组。解析时采用逐层映射策略// 嵌套 JSON - CommentDataModel[]与 CommentViewModel 数据结构对应functionparseComments(body:string):CommentDataModel[]{constrawJSON.parse(body)asArray{id?:number;name?:string;content?:string;likes?:string;date?:string;location?:string;replys?:Array{id?:number;name?:string;content?:string};};returnraw.map((item)newCommentDataModel(item.id,undefined,item.name,item.likes,item.content,item.date,item.location,item.replys?.map((r)newReplyDataModel(r.id,r.name,r.content))));}注意pic字段PixelMap | ResourceStr | DrawableDescriptor在此处传undefined——位图与资源引用属于运行时对象无法从 JSON 还原。正确的做法是传输层只传资源标识如ic_user01解析层viewModel再映射为$r(app.media.ic_user01)。这正是传输数据与展示数据的分层JSON 承载可序列化的基础类型资源映射收敛在模型转换的边界上。五、ArkTS 序列化限制与 ohos.util 辅助ArkTS 对运行时对象能力有严格约束序列化相关限制尤其值得注意限制说明规避方案禁止eval/new Function无法动态执行代码静态map转换对象字面量受限无Record任意键操作用 class 承载结构函数不可序列化stringify静默丢弃方法模型类只存数据联合类型字段pic等复杂类型无法直传传输层用字符串标识循环引用stringify直接抛异常模型禁止互相回指kit.ArkTS的ohos.util提供 JSON 之外的辅助工具例如用util.generateRandomUUID()生成稳定的列表 key替代字符串化大对象import{util}fromkit.ArkTS;constuuidutil.generateRandomUUID();// 生成全局唯一 ID// 可用作评论临时 idnew CommentDataModel(uuid, ...)对于大对象序列化项目还常借助JSON.parse(JSON.stringify(obj))做深拷贝。要注意其性能开销随对象体积线性增长且会丢失undefined与函数——频繁或大规模场景应改用显式字段拷贝。六、本地 mock 与真实网络数据的转换项目的 viewModel如CommentViewModel、WorksViewModel目前以$r()资源直接构造模型。演进为网络数据源后需在 viewModel 内完成JSON ↔ 模型 ↔ 资源三层转换且保持对外接口getCommentList()等不变// 统一入口本地 mock 与网络数据都转换为 CommentDataModel[]UI 无感知exportclassCommentViewModel{privatecommentList:CommentDataModel[][];asyncload():Promisevoid{// 1. 本地 mock现有逻辑作为兜底// 2. 网络 JSON第 38 篇parseComments(body) 得到模型// 3. 资源映射name/likes 由 JSON 字符串转为 $r() 或原样字符串}getCommentList():CommentDataModel[]{returnthis.commentList;}}转换规范遵循三原则传输层只用基础类型string/number/boolean/数组保证 JSON 可序列化展示资源在 viewModel 层映射模型字段与资源 API 解耦解析失败降级到 mock 数据任何 JSON 异常都不让 UI 空白。这样 JSON 解析逻辑与业务 UI 完全解耦本地开发与线上环境切换只改load()内部实现。七、总结与最佳实践stringify的 key 用法适合小对象大数据集改用id或util.generateRandomUUID()提升性能JSON.parse返回值的as强转不提供运行时保护必须逐字段校验并在构造函数兜底嵌套结构采用逐层 map 到模型类的解析策略与第 36 篇的嵌套模型一一对应位图、资源、函数等运行时对象不可 JSON 化传输层用标识字符串展示层再映射ArkTS 禁止eval/new Function序列化只适用于纯数据 class模型禁止循环引用深拷贝用JSON.parse(JSON.stringify(obj))有性能与语义损耗大数据量改显式拷贝转换逻辑统一收敛在 viewModelmock 与网络数据通过同一接口对外保证 UI 无感切换解析失败一律降级到 mock 或空列表任何 JSON 异常不得抛到 UI 层。