LitJson解析城市天气JSON：天气演示资源包实战指南

简介：这份资源面向Unity开发初学者与需要接入天气功能的移动端开发者，提供一套可直接运行的天气信息与城市定位演示工程，重点解决JSON数据解析、天气图标匹配与城市编码查询三个常见环节的落地问题。压缩包共57个文件，以46个PNG天气图标、10个C#脚本和1个JSON数据文件为主，图标覆盖晴、多云、暴雨、雾霾、沙尘等常见天气状态，脚本部分包含LitJson解析库的完整源码，city.json则保存城市与编码的对应关系，整体约436KB，体积轻便便于快速导入项目。已有1004人学习下载，说明该示例在同类需求中具备一定参考价值。读者可从中获得LitJson读取JSON的完整实现、天气图标与状态码的映射思路，以及城市编码数据的组织方式，适合作为天气模块开发的原型参考或教学素材。

1. 一个天气演示资源包，为什么值得单独拆一遍

上周有个做移动端的朋友甩过来一个压缩包，名字叫WeatherDemoAssets.zip，说是在某个素材站翻到的，想拿它做个天气类小应用的原型，问我值不值得用。我打开看了一眼，里面是一套天气演示用的资源集合，配套的关键词是 LitJson、weather、city、json——这几个词凑在一起，基本就把它的定位说清楚了：一套围绕城市天气数据、用 JSON 做数据交换、用 LitJson 做解析的演示素材包。它解决的不是“从零写一个天气 App”的问题，而是“我手上有个界面原型，缺一套能跑起来的数据和解析链路”的问题。适合谁？适合正在做课程设计、想快速搭一个能演示的天气模块、又不想自己造数据结构的开发者。下面我按自己拆包的习惯，把这份资源怎么用、参数怎么配、哪里容易翻车讲透。

2. 先看清数据链路：LitJson 解析城市天气 JSON 的完整走法

拿到这类资源包，我一般不会急着往工程里拖，而是先把数据链路在脑子里过一遍：城市列表从哪来、天气 JSON 长什么样、用 LitJson 反序列化成什么对象、界面层怎么消费。这条链路不通，后面贴多少代码都是白搭。这一章就把这条链路拆开，顺带说清楚为什么这类演示包偏爱 LitJson 而不是别的解析库。

2.1 为什么是 LitJson：轻量解析库的选型理由

LitJson 是一个面向 .NET / Unity 场景的轻量 JSON 解析库，最大的特点是体积小、API 直白、对JsonData这种动态结构支持得比较顺手。天气演示这种场景，数据结构往往不是特别规整——有的接口返回{"city":"北京","temp":"12"}，有的返回{"city":"北京","temp":12}，字段类型飘忽不定。用强类型反序列化库，遇到类型不一致直接抛异常；用 LitJson 的JsonData，可以先按动态结构读出来，再按需取值，容错空间大一些。

常见做法是：把天气 JSON 当成“半结构化数据”处理，先用JsonMapper.ToObject拿到JsonData，再逐字段取值并做类型判断。这样即使某个城市缺了humidity字段，也不会整个解析崩掉。代价是代码里会多一些判空和类型转换，但对演示项目来说，这点冗余换来的是“数据脏一点也能跑”，很划算。

需要提醒的是，LitJson 对中文的处理依赖文件编码。资源包里的 JSON 如果是 UTF-8 无 BOM，直接读没问题；如果是带 BOM 的 UTF-8 或者 GBK，读出来中文城市名会变乱码。这一点后面避坑章节会细说。

2.2 城市列表与天气 JSON 的字段约定

这类演示资源包通常包含两类 JSON：一类是城市清单，形如[{"id":1,"name":"北京"},{"id":2,"name":"上海"}]；另一类是每个城市对应的天气数据，形如{"cityId":1,"cityName":"北京","weather":"晴","temperature":12,"wind":"西北风3级"}。字段名不一定完全一样，但结构大同小异。

我一般会先写一个字段对照表，把资源包里的实际字段和代码里要用的字段对齐，避免后面改一处漏一处：

这张表不是让你照抄，而是让你在动手前先确认资源包里到底有哪些字段。我见过有人直接按记忆写代码，结果资源包里温度字段叫temp不叫temperature，跑起来全是默认值，排查半天才发现是字段名对不上。血泪经验：先cat一遍 JSON，再写映射。

2.3 用 LitJson 反序列化的最小可跑代码

下面这段是我在这个资源包场景下常用的最小解析骨架，语言是 C#，适用于 Unity 或普通 .NET 控制台工程：

using System; using System.IO; using LitJson; public class WeatherParser { // 读取城市列表，返回 JsonData 数组 public static JsonData LoadCityList(string path) { string raw = File.ReadAllText(path); // 注意编码，默认按 UTF-8 读 JsonData cities = JsonMapper.ToObject(raw); // 顶层是数组时直接得到 JsonData return cities; } // 解析单个城市的天气 JSON public static void ParseWeather(string path) { string raw = File.ReadAllText(path); JsonData data = JsonMapper.ToObject(raw); // 必填字段直接取，缺字段会抛异常，所以先判存在 if (!data.ContainsKey("cityName") || !data.ContainsKey("temperature")) { Console.WriteLine("字段缺失，跳过该条"); return; } string city = (string)data["cityName"]; // 温度可能是数字也可能是字符串，做一次兼容 int temp = data["temperature"].IsInt ? (int)data["temperature"] : int.Parse((string)data["temperature"]); // 可选字段用 TryGet 风格处理 string wind = data.ContainsKey("wind") ? (string)data["wind"] : "未知"; Console.WriteLine($"{city} 温度 {temp} 风力 {wind}"); } }

逻辑说明：JsonMapper.ToObject把字符串转成JsonData，这是 LitJson 的核心入口。ContainsKey用来判断字段是否存在，避免直接索引不存在的键抛异常。IsInt是JsonData自带的类型判断属性，用来兼容“温度有时是数字有时是字符串”的脏数据。参数方面，path指向资源包解压后的 JSON 文件路径，建议用绝对路径调试，确认能读通再改成相对路径。

这里有个细节：File.ReadAllText默认按 UTF-8 读，如果资源包里的 JSON 是 GBK 编码，中文会乱码。稳妥做法是显式指定编码，比如File.ReadAllText(path, Encoding.GetEncoding("GBK"))，但前提是你确认了文件编码。不确定就先按 UTF-8 读，乱码了再换，别一上来就猜。

2.4 把解析结果接到界面层：数据对象的落地方式

解析出来只是第一步，真正要跑起来还得把数据喂给界面。演示项目里常见的做法是定义一个轻量的WeatherItem类，把JsonData转成强类型对象再传给 UI 层，这样界面代码不用到处写(string)data["xxx"]：

public class WeatherItem { public int CityId; public string CityName; public string Weather; public int Temperature; public string Wind; public static WeatherItem FromJson(JsonData data) { return new WeatherItem { CityId = data.ContainsKey("cityId") ? (int)data["cityId"] : 0, CityName = data.ContainsKey("cityName") ? (string)data["cityName"] : "", Weather = data.ContainsKey("weather") ? (string)data["weather"] : "", Temperature = data.ContainsKey("temperature") ? (int)data["temperature"] : 0, Wind = data.ContainsKey("wind") ? (string)data["wind"] : "未知" }; } }

这样做的价值在于：解析逻辑和界面逻辑解耦，后面换数据源、加字段，只改FromJson一处。参数上注意CityId用int而不是string，因为城市编号通常用于索引匹配，用数字类型比较和查找都方便。如果资源包里cityId是字符串形式，记得在FromJson里做一次int.Parse，别直接强转，强转字符串到 int 在 LitJson 里会抛异常。

3. 资源包落地到工程：目录组织、编码与加载顺序

链路通了，接下来是把资源包真正塞进工程。这一步看着琐碎，但翻车率不低——路径写错、编码不对、加载顺序乱了，都会让演示跑不起来。这一章按我实际落地的顺序讲：先定目录，再处理编码，最后理清加载顺序。

3.1 目录怎么摆：资源、脚本、配置分离

我一般不会把资源包原样拖进工程根目录，而是按用途拆开。典型摆法是这样：

Assets/ WeatherDemo/ Data/ cities.json weather_beijing.json weather_shanghai.json Scripts/ WeatherParser.cs WeatherItem.cs Config/ weather_config.json

Data放原始 JSON，Scripts放解析代码，Config放路径配置或环境相关参数。这样摆的好处是：换数据源只动Data，改解析逻辑只动Scripts，路径调整只动Config，互不干扰。参数上，weather_config.json里可以放一个dataRoot字段指向Data目录，代码里读配置拼路径，避免硬编码。

注意：Unity 工程里Assets下的文件会被打包，如果 JSON 很大或者只是调试用，可以放到StreamingAssets下用Application.streamingAssetsPath读，但那样在部分平台上不能直接用File.ReadAllText，得走UnityWebRequest。演示项目数据量小，放Assets下用Resources.Load<TextAsset>读也行，看你的工程习惯。

3.2 编码统一：UTF-8 无 BOM 是底线

前面提过中文乱码的问题，这里展开说。资源包里的 JSON 如果是别人导出的，编码可能五花八门。我落地前会先跑一遍检查：

# 查看文件编码，file 命令能给出大致判断 file -i cities.json # 如果是 utf-8 但带 BOM，用 sed 去掉 BOM sed -i '1s/^\xEF\xBB\xBF//' cities.json # 如果是 gbk，转成 utf-8 iconv -f GBK -t UTF-8 cities.json -o cities_utf8.json

逻辑说明：file -i输出charset=utf-8或charset=iso-8859-1之类的信息，帮你判断编码。BOM 是 UTF-8 文件开头三个不可见字节，LitJson 读到会当成普通字符，导致第一个字段名解析失败，现象是“明明有数据却读出来是空”。sed那行专门去 BOM，iconv那行做编码转换。参数上注意iconv转换后建议另存新文件，别直接覆盖原文件，万一转错了还有后悔药。

统一成 UTF-8 无 BOM 之后，File.ReadAllText默认读取就不会乱码，代码里也不用到处写编码参数，省心。

3.3 加载顺序：先城市列表，再按需加载天气

演示项目常见的错误是“一次性把所有天气 JSON 全读进来”，城市一多就卡。正确顺序是：先加载城市列表，界面渲染出城市选择；用户选中某个城市后，再按cityId去加载对应的天气 JSON。这样首屏只读一个小文件，响应快。

代码上可以这样组织：

// 第一步：加载城市列表 JsonData cities = WeatherParser.LoadCityList(config.DataRoot + "/cities.json"); // 第二步：根据选中城市拼天气文件路径 int selectedId = 1; // 来自界面选择 string weatherPath = $"{config.DataRoot}/weather_{selectedId}.json"; // 第三步：按需解析 WeatherParser.ParseWeather(weatherPath);

参数说明：config.DataRoot来自配置文件，selectedId来自界面交互。这里的关键是“按需”二字——别在启动时把所有天气文件都读一遍。如果资源包里天气文件命名不是weather_{id}.json这种规律，就在城市列表里加一个dataFile字段直接存文件名，代码里读这个字段拼路径，比猜命名规则靠谱。

4. 避坑与排查：这类演示包最容易翻车的五个地方

资源包能不能用，往往不取决于它功能多全，而取决于那几个隐蔽的坑你有没有提前踩过。下面五条是我拆这类天气演示包时反复遇到的，按“现象 → 原因 → 解决”写，照着排查能省不少时间。

4.1 现象：解析报错“Invalid character”，原因多半是 BOM 或编码

现象很典型：JsonMapper.ToObject一调用就抛异常，提示非法字符，但你把 JSON 贴到在线校验工具里又是合法的。原因基本是文件带 BOM 或者编码不是 UTF-8。解决：按 3.2 节的方法去 BOM、转 UTF-8，再读。如果还不行，用十六进制工具看一眼文件头，确认没有隐藏字符。

4.2 现象：中文城市名显示成问号或乱码，原因是读取编码和文件编码不一致

代码里File.ReadAllText默认 UTF-8，文件实际是 GBK，中文就乱。解决：先确认文件编码，再显式指定读取编码，或者干脆把文件转成 UTF-8。别在代码里同时混用两种编码读不同文件，统一成一种最省事。

4.3 现象：温度字段读出来是 0，原因是字段名或类型对不上

资源包里温度字段可能叫temp、temperature、tempC，类型可能是数字也可能是字符串。代码里按temperature取，取不到就落到默认值 0，看起来像“数据没读到”。解决：先打印原始 JSON 的键名，确认字段名；再用IsInt/IsString做类型兼容。别假设字段名和你想的一样。

4.4 现象：切换城市后天气不更新，原因是路径拼接或缓存没清

演示项目里常见：第一次加载正常，切换城市后还是旧数据。原因通常是天气文件路径拼错了（比如cityId和文件名对不上），或者解析结果被缓存了没刷新。解决：在切换城市时打印实际请求的路径，确认文件存在；如果用了缓存，切换时清掉对应 key。路径拼接建议用Path.Combine，别手写斜杠，跨平台不容易错。

4.5 现象：打包后读不到 JSON，原因是资源没被打进包或路径用了绝对路径

编辑器里跑得好好的，一打包就报文件不存在。原因多半是 JSON 放在Assets外，或者代码里用了绝对路径。解决：确认 JSON 在Assets或StreamingAssets下，读取用Resources.Load或Application.streamingAssetsPath拼相对路径。绝对路径只在编辑器调试时用，别带进发布代码。

5. 进阶用法：把演示数据换成真实接口前的验证清单

这份资源包的价值不只是“能演示”，更在于它是一套可替换的数据骨架。等你把演示跑通，下一步多半是想接真实天气接口。接之前，我习惯先做一轮验证，确认解析层能扛住真实数据的“脏”。具体做法是：拿资源包里的 JSON 结构当契约，写一个小的校验脚本，把真实接口返回的样本丢进去跑一遍，看字段缺失、类型漂移、嵌套层级变化这三种情况会不会让解析崩掉。

// 校验入口：传入任意 JSON 字符串，输出结构兼容性报告 public static void ValidateSchema(string raw) { try { JsonData data = JsonMapper.ToObject(raw); Console.WriteLine("顶层类型: " + data.GetJsonType()); // 检查关键字段是否存在 string[] required = { "cityName", "temperature", "weather" }; foreach (var key in required) { Console.WriteLine($"{key}: {(data.ContainsKey(key) ? "存在" : "缺失")}"); } // 检查温度类型是否漂移 if (data.ContainsKey("temperature")) { Console.WriteLine("temperature 类型: " + data["temperature"].GetJsonType()); } } catch (Exception e) { Console.WriteLine("解析失败: " + e.Message); } }

这段代码的参数就一个raw，传真实接口的响应字符串即可。输出会告诉你顶层是对象还是数组、关键字段在不在、温度是 Int 还是 String。我一般会拿五到十个不同城市的真实响应跑一遍，如果temperature类型在 Int 和 String 之间反复横跳，就在FromJson里把兼容逻辑写死，别等到线上才发现。

还有一个技巧：把资源包里的cities.json当成“城市白名单”，真实接口返回的城市如果不在白名单里，就按cityName做一次模糊匹配再落库。这样既复用了演示数据，又避免了真实数据里城市名带“市”字、带拼音后缀导致的匹配失败。匹配规则建议单独抽一个方法，参数是rawName和whitelist，返回标准城市名，方便后面加规则。

从那以后我每次接真实数据源前，都会先用演示包的 JSON 结构跑一遍这个校验，确认解析层不会因为一个字段类型变化就整条链路崩掉。这份WeatherDemoAssets.zip本身不大，但把它当成“数据契约的参照物”来用，比单纯跑个演示值当得多。希望帮到你。

本文还有配套的精品资源，点击获取