简介：这份资源面向Unity开发初学者与需要接入天气功能的移动端开发者，提供一套可直接运行的天气信息与城市定位演示工程，重点解决JSON数据解析、天气图标匹配与城市编码查询三个常见环节的落地问题。压缩包共57个文件，以46张天气状态PNG图标、10个C#脚本和1个城市编码JSON文件为主，图标覆盖晴、多云、雷阵雨、雾霾、沙尘暴等常见天气类型，脚本部分包含LitJson解析库的完整实现，整体约436KB，体积轻便便于快速导入项目。已有1004人学习下载，适合作为课程作业、毕业设计或小型App的参考素材。读者可从中获得LitJson读取JSON的完整代码结构、天气图标与状态码的对应关系，以及city.json中城市名称与city_code的映射数据，便于直接替换数据源或扩展为实时天气接口调用，减少从零搭建数据层与图标资源的时间成本。

1. 天气数据驱动的城市信息演示：从一份资源包看 LitJson 与 city json 的配合

第一次拿到 WeatherDemoAssets.zip 这个包，我以为是几张天气图标加一份说明文档，解压后才发现里面是一套围绕城市天气数据做展示的演示资源：城市列表、天气状态、图标素材，以及用 LitJson 解析 city json 的示例数据。它解决的不是“做一个完整天气 App”的问题，而是把“城市维度 + 天气状态 + JSON 数据驱动 UI”这条链路拆成可复用的素材和最小示例，适合正在做天气类 Demo、需要快速搭出城市切换和天气展示界面的开发者。LitJson 在这里承担的是把 city json 转成运行时对象的角色，资源包则负责把城市、天气、图标这些静态内容准备好，让你不用从零造数据。下面按“能干什么、怎么跑、怎么改”的顺序拆开讲。

2. 资源结构与技术选型：city json 如何驱动天气展示

2.1 包内目录与文件职责

WeatherDemoAssets.zip 解压后大致是资源目录加示例脚本的结构。不同人拿到的包可能略有差异，但核心组成通常如下表所示。我按常见做法把职责列清楚，你对照自己解压出来的文件就能对上号。

这里的关键不是文件多，而是 city json 和天气图标之间靠一个字段建立映射。常见做法是 city.json 里每个城市对象带一个 weatherCode，weather.json 里用 weatherCode 作为键去查图标和描述。这样城市列表和天气表现解耦，后面加城市只改数据不改代码。

2.2 为什么选 LitJson 而不是别的 JSON 库

LitJson 的特点是轻量、API 直接，适合演示和小型项目。它把 JSON 字符串转成 JsonData，再通过索引或强类型映射取字段，不需要额外生成代码。对于 city json 这种结构固定、字段不多的数据，LitJson 的 JsonMapper.ToObject () 足够用，写起来比手写解析短很多。代价是它对复杂嵌套和类型推断不如一些大型序列化库稳，字段类型不一致时容易在运行时才暴露。演示资源包选它，图的就是“打开就能跑、改起来不绕”。

我一般会在数据模型里把字段类型写死，避免 LitJson 把数字解析成字符串导致后续比较出错。比如城市编号用 int，天气代码用 string，图标路径用 string，这样映射到 UI 时不用再做二次转换。

2.3 数据模型与字段约定

演示包里的 city json 通常长这样，字段名可能略有不同，但结构类似：

{ "cities": [ { "id": 1001, "name": "示例城", "region": "北方", "weatherCode": "sunny", "temperature": 26 }, { "id": 1002, "name": "演示市", "region": "南方", "weatherCode": "rain", "temperature": 19 } ] }

对应到代码里，我一般定义两个类：一个描述单个城市，一个描述城市列表容器。LitJson 映射时要求字段名和 JSON 键一致，大小写敏感，所以命名要统一。如果 JSON 里是 weatherCode，类里就不能写成 WeatherCode，除非加映射配置。演示资源包通常已经对齐，二次开发时改字段要两边一起改。

3. 跑起来：从解压到场景运行的完整步骤

3.1 环境准备与导入

这个资源包是演示素材加脚本，常见运行环境是 Unity 一类支持 C# 的引擎，因为 LitJson 的 C# 版本和资源目录结构都指向这个方向。如果你用的是其他环境，核心逻辑可以照搬，只是加载路径和 UI 绑定要换。导入步骤我按通用流程写：

1. 解压 WeatherDemoAssets.zip，得到资源目录。
2. 新建或打开一个空项目，把资源目录整体拖入项目的 Assets 下。
3. 确认 LitJson 的源码或 DLL 在工程内，演示包一般自带，若没有则补一个 LitJson 的 C# 实现。
4. 打开演示场景，检查场景里是否已挂载数据加载脚本和 UI 根节点。
5. 运行，观察城市列表和天气图标是否按 city json 的内容显示。

这一步最容易翻车的地方是路径。演示脚本里常用相对路径或 Resources 加载，如果你把文件挪了位置，加载会返回空。先按原目录结构跑通，再谈改造。

3.2 加载 city json 并解析

下面是一段典型的加载与解析代码，演示包里的写法可能更简，但逻辑一致：

using LitJson; using System.IO; using UnityEngine; public class CityDataLoader : MonoBehaviour { // 城市列表容器，字段名与 city.json 顶层键对应 public class CityList { public CityItem[] cities; } public class CityItem { public int id; public string name; public string region; public string weatherCode; public int temperature; } public CityList LoadCities(string jsonPath) { // 读取 json 文本，路径按工程内实际位置调整 string jsonText = File.ReadAllText(jsonPath); // LitJson 直接映射到强类型对象 CityList list = JsonMapper.ToObject<CityList>(jsonText); return list; } }

这段代码做了三件事：读文件、用 JsonMapper 映射、返回强类型列表。参数上，jsonPath 要指向 city.json 的实际路径；CityList 的字段名必须和 JSON 顶层键一致；CityItem 的字段类型要和 JSON 值匹配。如果运行时报“类型转换失败”，先查 JSON 里有没有把数字写成字符串，或者字段名大小写不一致。LitJson 在这类错误上提示不算友好，血泪经验是先用一个最小 JSON 试映射，确认模型对了再换完整数据。

3.3 把天气状态映射到图标

解析出城市列表后，下一步是按 weatherCode 找图标。常见做法是维护一个字典，键是天气代码，值是图标资源名或路径：

using System.Collections.Generic; using UnityEngine; public class WeatherIconMapper : MonoBehaviour { // 天气代码到图标名的映射，演示包通常用命名约定 private Dictionary<string, string> iconMap = new Dictionary<string, string> { { "sunny", "Weather/Sun" }, { "cloudy", "Weather/Cloud" }, { "rain", "Weather/Rain" }, { "snow", "Weather/Snow" } }; public Sprite GetIcon(string weatherCode) { if (iconMap.TryGetValue(weatherCode, out string iconName)) { // 按资源路径加载图标 return Resources.Load<Sprite>(iconName); } // 未知天气代码回退到默认图标，避免界面空白 return Resources.Load<Sprite>("Weather/Default"); } }

这里的参数说明：weatherCode 来自 city json，必须和字典键完全一致；Resources.Load 的路径相对于 Resources 目录，如果演示包用的是直接引用而非 Resources，改成公开字段拖拽即可。回退分支很重要，city json 里出现未登记的天气代码时，界面不会空一块。我一般会把回退图标也放进资源包，避免二次开发时漏掉。

3.4 刷新 UI 与验证数据链路

数据解析和图标映射都通了之后，最后一步是把结果刷到界面上。演示场景里通常有一个列表容器和一个详情区，列表项显示城市名和温度，详情区显示天气图标。验证方法很直接：改 city.json 里某个城市的 temperature，重新运行，看界面数字是否跟着变；改 weatherCode，看图标是否切换。两步都生效，说明从 json 到 UI 的链路是通的。如果数字变了图标没变，问题在映射字典或资源路径；如果都没变，问题在加载路径或解析异常被吞掉。建议在加载处加一行日志输出解析到的城市数量，这是最快的定位手段。

4. 核心代码拆解：LitJson 解析与数据校验的关键点

4.1 强类型映射与容错处理

LitJson 的 JsonMapper.ToObject () 在字段缺失时不会报错，缺失字段会保留默认值。这个特性对演示友好，但对二次开发是隐患：city json 少一个 weatherCode，界面就会走回退图标，你以为是映射错了，其实是数据缺字段。我一般会在解析后做一轮校验：

public bool ValidateCities(CityList list, out string error) { error = string.Empty; if (list == null || list.cities == null || list.cities.Length == 0) { error = "城市列表为空"; return false; } foreach (var city in list.cities) { // 必填字段检查，避免空值流入 UI if (string.IsNullOrEmpty(city.name) || string.IsNullOrEmpty(city.weatherCode)) { error = $"城市数据不完整: id={city.id}"; return false; } } return true; }

这段校验放在解析之后、刷新 UI 之前。参数上，list 是映射结果，error 输出具体哪条数据有问题。演示包不一定带这段，但二次开发时加上能省很多排查时间。LitJson 不会告诉你哪一行缺字段，只能自己补这层检查。

4.2 天气代码与图标的解耦设计

前面提到的字典映射是最直接的做法，但城市多了之后，天气代码可能扩展。更稳的做法是把天气代码和图标名的对应关系也放进 json，而不是写死在代码里。演示包如果只给了 city json，你可以自己加一个 weather.json，结构如下：

{ "weathers": [ { "code": "sunny", "icon": "Weather/Sun", "label": "晴" }, { "code": "rain", "icon": "Weather/Rain", "label": "雨" } ] }

解析方式与 city json 相同，用 LitJson 映射成 WeatherList。这样加一种天气只改数据，不动代码。代价是多一次加载和一次字典构建，对演示规模完全可以接受。我一般会在初始化时把 weather.json 读成字典缓存起来，后续按 code 查，避免每次刷新都遍历。

4.3 城市列表的排序与筛选入口

演示包里的城市顺序通常就是 json 里的顺序。实际使用时，按区域分组或按名称排序更常见。因为数据已经在内存里，排序不需要再碰 json：

using System.Linq; public CityItem[] SortByRegion(CityList list) { // 先按区域，再按名称，保证展示稳定 return list.cities .OrderBy(c => c.region) .ThenBy(c => c.name) .ToArray(); }

这段不是演示包必带，但它是二次开发最常加的一步。参数上没有额外配置，直接对解析结果操作。注意排序后如果 UI 用索引绑定数据，要同步更新索引映射，否则点击列表项会取错城市。这是我在类似 Demo 上踩过的坑：列表显示顺序变了，点击回调还按原始索引取，结果详情区和列表对不上。

5. 避坑与排查：city json 解析和资源加载的常见问题

5.1 解析报类型转换异常

现象：运行到 JsonMapper.ToObject 时抛异常，提示无法把某个值转成目标类型。原因通常是 JSON 里数字被写成字符串，或者字段名大小写与类不一致导致 LitJson 走了默认转换路径。解决：先用最小 JSON 单独测映射，确认每个字段类型；把类字段和 JSON 键逐字对齐；数字字段不要加引号。演示包里如果混用了两种写法，统一成一种再跑。

5.2 城市列表显示为空

现象：场景运行后列表没有任何项，也没有明显报错。原因多为加载路径不对，File.ReadAllText 读到了空内容或异常被吞。解决：在读取后打印 jsonText 长度，长度为 0 就是路径问题；检查文件是否在预期目录、扩展名是否被系统隐藏。另一个常见原因是顶层键名和容器类字段不一致，比如 JSON 是 cityList 而类里写 cities，映射结果为空但不报错。

5.3 天气图标不显示或显示错位

现象：城市名和温度正常，图标区域空白或全是默认图。原因一是 weatherCode 在映射字典里不存在，走了回退；二是 Resources 路径和实际目录不一致；三是图标命名带空格或大小写差异。解决：打印每个城市的 weatherCode，对照字典键；用 Resources.Load 的返回值判断是否为空；把图标文件名和 json 里的值做成完全一致，避免靠猜。

5.4 修改 json 后运行没变化

现象：改了 city.json 的温度或城市名，重新运行界面还是旧数据。原因可能是工程里存在多份同名文件，加载的是另一份；也可能是编辑器缓存了资源，没有重新导入。解决：全局搜索文件名确认只有一份；在编辑器里刷新或重新导入资源；如果是打包后运行，确认改的是打包内那份而不是源目录。这个坑很隐蔽，我一般会在加载日志里带上完整路径，一眼就能看出读的是哪个文件。

5.5 中文城市名出现乱码

现象：城市名显示为问号或乱码。原因多为文件编码不是 UTF-8，或者读取时用了不匹配的编码。解决：把 city.json 统一存为 UTF-8；读取时显式指定编码；确认编辑器或运行环境的默认编码一致。演示数据里中文不少，这一步不做，后面所有展示都会受影响。

6. 二次开发：把演示资源改成可维护的天气数据层

演示包的价值不在它本身多完整，而在于它把 city json、LitJson 解析、图标映射这条链路摆出来了。二次开发时我建议先做一件事：把“数据加载”和“界面刷新”拆成两个独立模块，中间用一个城市数据列表传递。这样换数据源（比如从本地 json 换成接口返回）时，只改加载模块，界面不动。具体做法是定义一个 ICityDataSource 接口，演示包里的本地文件加载实现它，后续加网络加载再实现一个，调用方只依赖接口。

第二个改造点是字段扩展。city json 里加字段时，同步改数据模型和校验逻辑，不要只改一边。我习惯在模型类里给新增字段一个明确默认值，并在校验里决定它是必填还是可选，避免 LitJson 缺字段时静默通过。第三个点是图标映射外置，前面提过，把 weather.json 独立出来后，天气代码的增删不再碰代码，这对后续接真实天气数据很关键，因为真实接口返回的天气代码往往和演示数据不一致，需要一层映射转换。

验证改造是否成功，我一般用三个检查：改一条城市数据看界面是否跟随；加一个未登记的天气代码看是否走回退而不是崩溃；把数据文件换个目录看加载是否按预期报错而不是静默为空。三个都过，这条数据链路才算稳。从那以后我每次接类似的城市天气演示资源，都强制先跑一遍“改数据、看界面、查日志”的闭环，再动界面代码，希望帮到你。

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