企业官网建设流程全解析

简介：面向计算机软件专业毕业设计的 iOS 平台天气 App 应用设计与实现文献综述文档，适合正在准备开题报告或文献综述章节的同学参考。文档先以移动互联网为背景，从概念、现状和基本特点入手展开论述，并引用移动用户规模与 App Store 应用增长数据，说明天气 App 兴起的行业环境；还分析了移动互联网在终端、网络、服务、安全隐私等方面面临的挑战。随后聚焦天气 App 本身，总结出 iOS 平台天气 App 设计应当关注的用户体验、实时数据获取、功能集成、个性化设置、安全性以及技术创新等关键问题，为毕业设计提供了明确的论述方向。资源共 1 个文件，为 doc 格式文档，压缩包约 48KB，内容以文字论述为主，可直接在 Word 中打开阅读；对于缺乏综述写作思路的同学，它既给出了清晰的章节结构和论述逻辑，也提供了可引用的行业数据与设计建议，能帮助快速搭建文献综述框架。目前已有 215 人学习浏览，适合作为同类毕业设计选题的参考资料。

1. 别急着写代码：为什么「文献综述」才是 iOS 天气项目的第一个拦路题

很多计算机专业的同学拿到毕业设计题目「基于 ios 平台的天气 app 应用设计与实现」之后，第一反应是打开 Xcode 开始堆界面，结果在开题报告和文献综述上被导师打回来三遍。天气 App 看起来门槛低——拉个列表、请求一下天气接口就能跑，但真要把综述写到能指导开发，你会发现自己绕不开 iOS 的定位权限、网络层设计、数据缓存、UI 状态管理、上架签名这些硬问题。这篇综述不是凑字数，它本质上是一份「技术选型决策清单」。本文就按「综述里怎么写，代码就怎么落」的思路，把这条路线完整拆一遍，适合正在定题、正在写开题报告，或者综述已经写完但不知道下一步怎么动手的同学。

2. 从综述到选型清单：先用一页纸定死语言、UI 体系、天气数据源和架构

2.1 选语言和 UI 框架：Swift + SwiftUI 还是 UIKit？

文献综述的第一个技术判断点，是技术栈。现在打开 Xcode 新建项目，默认模板里你会在 UIKit（Storyboard 或纯代码）和 SwiftUI 之间二选一。我的建议很直接：如果你的综述里引用了 iOS 15 之后的官方文档和 WWDC 内容，就用 Swift + SwiftUI；如果你参考的文献大多停留在 2019 年之前，或者你实习时写过 Objective-C，那选 UIKit 更稳妥。

不要小看这个决定。SwiftUI 的写法在 2020 年之后出现了很多变化，例如@ObservedObject、@StateObject的区分，iOS 17 之后又加入了@Observable宏。如果你在综述里承诺了「基于 SwiftUI 构建响应式界面」，后面写代码就会按照这个承诺走；反过来，如果你的综述大篇幅在讲 MVC 和 ViewController 生命周期，SwiftUI 会让你的生命周期描述变得很难对上。

我在实际做这类毕设时，一般会用一张表格把技术栈锁死：

这个表格写进综述里，不只是给导师看，更重要的是你在后续三个月里不会再纠结「要不要换个跨平台框架」。很多同学在综述里写「本项目采用 SwiftUI 开发」，结果发现自己电脑上的 Xcode 版本太低，SwiftUI 支持不全，又回来改文档——这就是选型没有对照本地环境导致的返工。动手写代码之前，先确认你的 Xcode 版本和部署目标能对上。

2.2 天气数据源怎么调研：免费接口、字段差异与「够用」标准

文献综述里最容易被写成「百度介绍」的部分，就是数据源。天气 App 的核心是数据，数据源的调研直接决定你的功能边界。常见做法是调研三类数据源：国内的免费天气接口、国际开放接口、以及 iOS 系统自带的 WeatherKit。写综述时不要只抄接口文档，要做对比，对比的维度是：请求量限制、覆盖城市、字段丰富度、是否需要密钥、是否支持 HTTPS。

以免费接口为例，有的接口日请求上限在三千次左右，有的按城市列表返回，有的只支持当前天气不支持未来三天预报。这些限制在「设计与实现」阶段会变成很现实的问题——如果接口不支持城市搜索，你就得自己维护一个城市 ID 列表；如果接口限流很紧，你就必须做本地缓存和请求节流。综述里写一句「本系统选用 XX 接口，其日请求上限为 XX 次，可满足单用户正常使用」，一下子就把你的调研深度体现出来了。

我一般会把调研结果整理成下面的字段对比表写进综述：

这个表格的用处是让你在写代码阶段不用反复改接口。比如你发现调研时没注意城市搜索这个点，代码写到一半才补城市 ID 表，那电池电量、后台刷新这些功能可能都得往后让路。简而言之，综述里把「够用」两个字定义清楚，比把接口文档抄一遍有价值得多。

2.3 架构与状态管理：MVC/MVVM 在天气 App 里的取舍

天气 App 的功能边界通常不大，但它天然适合讨论架构，因为它的状态变化非常典型：开始请求、加载中、成功返回、失败重试、切换城市、刷新数据。综述里如果不讨论架构，后面代码几乎必然会写成「ViewController 里同时放网络请求和 UI 更新」的大杂烩。我见过很多毕设代码，启动后第一屏要等网络返回才显示，没有任何中间态，用户也不知道是卡了还是坏了。

如果你选 SwiftUI，MVVM 是阻力最小的方向。ViewModel 持有天气数据模型和加载状态，View 只负责渲染。用@StateObject持有 ViewModel，用@Published驱动 UI 更新。这样每个状态都能在 ViewModel 里定义成枚举：加载中、成功、失败、空数据。写综述的时候，把这些状态转换画成文字描述，或者写成一小段伪代码，比贴一张 MVC 架构图更有说服力。

不用把 MVVM 神话。它的代价是多了 ViewModel 层和绑定代码，对几十行的小 Demo 来说确实笨重。但毕业设计要的是「展示工程能力」和「可扩展性」，MVVM 天然方便你加缓存、加日志、加单元测试。一个折中的做法是：核心逻辑走 ViewModel，个别简单页面（比如设置页）直接用@State搞定，不要为了架构而架构。

2.4 综述结构和开发清单映射：让每个小节都变成代码里的一个文件

这是我自己写综述时最受用的一个思路：在文档里建一张「开发任务清单」，把综述每一小节的结论对应到未来工程里的一个文件或者一个模块。这样做的好处是，答辩被问到「你的综述有什么实际价值」时，你可以直接指出来——这一段选型结论对应的是WeatherService.swift，那一段缓存策略对应的是CacheManager.swift。

具体的映射关系可能是这样的：

这张表写进综述附录，导师会认为你把文献调研和系统设计打通了，而不是交了一篇「百度百科」。对你自己的价值更直接：后面每一步要做什么都清清楚楚，不会出现写着代码突然停下来想「我这个功能要不要做」的情况。综述中段的文献综述其实「综述」的不是论文，是「待开发的系统」——所有文献最终都要为这张表服务。

3. 在 Xcode 落地最小原型：从开发者模式到真机拉回第一条天气数据

3.1 创建项目：Bundle ID、部署目标与开发者模式设置

综述完成并审核通过后，就可以动手创建工程了。打开 Xcode，选择 App 模板，填项目名时注意一个细节：Product Name 用英文，不要在项目路径里带中文和空格，否则后面打证书包时容易踩坑。Team 一栏在个人免费调试阶段可以选 None，但你要真机运行，就必须在 Xcode 的 Settings -> Accounts 里登录 Apple ID，并选择 Personal Team。

在真机运行前，iOS 16 及以上版本的设备需要先在手机设置里打开「开发者模式」。具体路径是：设置 -> 隐私与安全性 -> 开发者模式，开启后会要求重启手机。这一步是很多第一次做 iOS 开发的同学会忽略的——模拟器跑得好好的，插上真机 Xcode 提示 "Developer Mode is disabled"，这不是项目问题，是设备设置问题。

创建项目时 Deployment Target 我会直接选 iOS 15.0。这个版本让 SwiftUI 的AsyncImage、Refreshable这些特性都能用，又不至于因为支持 iOS 14 而被迫写兼容代码。你可以在项目设置里看到一个部署目标选项，选低版本意味着更多用户能装，但代价是你要为老版本适配；选 iOS 15 是在「够用」和「省事」之间比较均衡的点。

3.2 网络层最小实现：URLSession 请求真实天气数据

不放模拟数据，直接请求真实接口，是验证选型最快的方式。下面这段代码是网络层的最小实现，它用URLSession发起异步请求，并把 JSON 数据通过Codable解码成天气模型：

import Foundation struct WeatherResponse: Codable { let temperature: Double let condition: String let humidity: Int } enum WeatherError: Error { case invalidURL case noData } class WeatherService { private let apiKey = "你的密钥" private let baseURL = "https://api.example.com/weather" func fetchWeather(cityID: String) async throws -> WeatherResponse { guard var components = URLComponents(string: baseURL) else { throw WeatherError.invalidURL } components.queryItems = [ URLQueryItem(name: "city", value: cityID), URLQueryItem(name: "key", value: apiKey) ] guard let url = components.url else { throw WeatherError.invalidURL } let (data, response) = try await URLSession.shared.data(from: url) guard let http = response as? HTTPURLResponse, http.statusCode == 200 else { throw WeatherError.noData } return try JSONDecoder().decode(WeatherResponse.self, from: data) } }

这段代码里要注意的是URLComponents，它比字符串拼接安全得多，城市名里有中文或特殊字符时会被正确转义。try await是 Swift 并发的新语法，比以前的闭包回调好读好维护，这也是综述里应该提到的「基于 Swift Concurrency 的异步网络层」。HTTPURLResponse的 statusCode 检查很关键，很多接口在密钥错误或限流时会返回 200 之外的码，不进这一步检查，你会拿一堆错误提示当正常数据看。

3.3 JSON 解码：把接口字段变成 Swift 类型

网络层返回的是 JSON 字符串，要变成界面能用的数据，还得做一次解码。有的接口字段名是temp_max这类下划线风格，而 Swift 的命名习惯是驼峰，这时不要手写CodingKeys枚举，直接让JSONDecoder开启keyDecodingStrategy更省事：

let decoder = JSONDecoder() decoder.keyDecodingStrategy = .convertFromSnakeCase

这行配置能把temp_max自动映射成tempMax，省掉一大段手工映射代码。如果你在综述里调研了多个接口，最好在设计模型时保留一个WeatherResponse，再写一个Weather业务模型，两者之间做转换。否则接口一换，你的界面代码和缓存代码全要跟着改。

3.4 定位与地理编码：拿到当前城市再请求天气

天气 App 的核心体验是「打开就知道本地天气」，不靠手动搜索，这就要求先定位，再把经纬度换算成城市名。CoreLocation的使用分为三块：请求权限、发起定位、地理编码。下面是定位管理器的最小实现：

import CoreLocation class LocationManager: NSObject, CLLocationManagerDelegate { private let manager = CLLocationManager() override init() { super.init() manager.delegate = self manager.requestWhenInUseAuthorization() } func locationManagerDidChangeAuthorization(_ manager: CLLocationManager) { switch manager.authorizationStatus { case .authorizedWhenInUse, .authorizedAlways: manager.requestLocation() case .denied, .restricted: print("用户拒绝了定位权限，走城市搜索兜底") default: break } } func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) { guard let location = locations.last else { return } let geocoder = CLGeocoder() geocoder.reverseGeocodeLocation(location) { placemark, _ in let city = placemark?.first?.locality ?? "未知城市" print("当前城市：\(city)") } } func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) { print("定位失败：\(error.localizedDescription)") } }

注意requestLocation()只回调一次定位结果，适合「打开 App 定位一次」的场景。如果你要做持续位置更新，应该换成startUpdatingLocation()，但天气 App 不需要，持续定位反而会让用户在设置里看到「天气正在后台使用定位」，白白增加审核和耗电压力。权限描述文案写在 Info.plist 的NSLocationWhenInUseUsageDescription里，最好写成「用于获取当前城市并显示对应的天气信息」，而不是敷衍的「需要定位」。

3.5 跑通后的检查清单

原型跑通不是结束，是真正的开始。我会按下面这张清单逐项过一遍，每过一项就在综述对应的章节后面打个勾：

• 冷启动后能在 5 秒内看到当前城市天气
• 模拟器和真机都能拿到定位，且城市名正确
• 明文接口被 ATS 拦截时报错清晰，不白屏
• 断网时界面有「加载失败」提示，可重试
• 城市名带「市」「区」后缀时，请求参数没有被错误截断

这一步做完，你手里就有了一个「可以演示的最小闭环」。下一步再谈权限、缓存和小组件，就有了讨论基础。

4. 权限、缓存与刷新：把「会跑的 Demo」做成「像样的设计与实现」

4.1 权限与隐私：Info.plist 里的文案决定你的审核命运

权限声明是 iOS 开发和安卓最大的区别之一，也是综述里好写、代码里容易漏的部分。iOS 对敏感权限是「使用前弹窗、设置里可关、系统强制展示用途」。天气 App 至少会用到定位权限，如果你要保存城市列表或数据到文件，可能涉及照片或通知权限，但通常都不需要。

我建议在工程里单独建一个Info.plist权限声明清单，和代码分开维护。钥匙串里的值必须是完整的「用途描述」，不能写简称。常见写法是：定位权限写「用于获取当前城市天气」，通知权限写「用于在降雨开始前提醒你」。别小看这段文案，App Store 审核时如果发现权限用途和实际功能不符，会被打回重新提交。综述里讨论「用户隐私保护设计」时，把这段文字设计和系统权限机制写进去，比空谈隐私政策有用得多。

4.2 缓存与离线兜底：从 UserDefaults 到内存缓存

天气数据有很强的时效性，但不代表每次打开 App 都要重新请求。聪明的做法是：把上次成功获取的数据存起来，下次启动时先展示缓存数据，再在后台刷新。最常见的是用UserDefaults存轻量数据，模型做Codable后可以直接编码成 Data 存进去：

struct CacheManager { private let key = "lastWeatherData" func save(_ weather: WeatherResponse) { if let data = try? JSONEncoder().encode(weather) { UserDefaults.standard.set(data, forKey: key) } } func load() -> WeatherResponse? { guard let data = UserDefaults.standard.data(forKey: key) else { return nil } return try? JSONDecoder().decode(WeatherResponse.self, from: data) } }

这段代码的逻辑是：启动时先调用load()，如果有数据就立刻显示；同时Task里发起网络请求，成功后save()并刷新 UI。这就是经典的「Stale-While-Revalidate」策略，写进综述里可以作为缓存策略的论证。注意UserDefaults不适合存大对象和频繁写，如果你的历史天气记录超过了上百条，就改存 SQLite 或文件目录，不需要引第三方库，用Codable直接写 JSON 文件也够。

4.3 后台刷新与小组件（Widget）是加分的「深一层」

天气 App 非常适合加 Widget，因为它本质上是「看一眼就走」的信息。iOS 的小组件基于WidgetKit，写一个小组件的工作量不大，但能显著提升答辩观感。它的核心是共享数据：主 App 写入天气数据的App Group容器，小组件读取同一份数据并渲染。注意普通UserDefaults在 App 和 Widget 之间不共享，必须用UserDefaults(suiteName: "group.xxx")。

后台刷新则是另一个可选项。iOS 的BGTaskScheduler能注册「刷新」任务，但系统实际执行时机受用户使用习惯和电量影响，不能保证准时。我见过不少同学在综述里夸下海口说「每 30 分钟自动刷新」，实际测试时根本触发不了那么频繁。正确的写法是「在系统允许的时机进行后台刷新，并在缓存策略中控制 UI 不出现过期数据」。你控制不了的机制，不要在文档里承诺死。

4.4 再回头看综述：把「已实现」回填成「设计与实现」

代码写完一部分后，我会建议把综述里对应的段落再改一遍。这听起来像「先写文档再写代码」的矛盾，但其实合理：文献综述阶段你写的是「前人怎么做」，设计与实现阶段你要写的是「我怎么做」。比如你调研时发现接口有分钟级限流，于是你在代码里加了 30 秒防抖和缓存，这个决策过程，就是论文里最有价值的「设计依据」。很多同学论文写不好，不是因为他们做得少，而是他们不把自己做过的取舍写进去。

综述和代码之间最好的关系是「可追踪」——每个设计点都能回到底层文献或实验对比。做不到这一点，答辩时老师问「你这个缓存时间为什么设 30 分钟」，你只能回答「我随便设的」，那印象分就掉了一大截。

5. 避坑：模拟器定位、ATS 拦截、接口限流和 SwiftUI 预览的 5 个翻车现场

5.1 模拟器定位失灵，天气永远显示「库比蒂诺」

现象：在 iOS 模拟器上运行 App，定位结果永远是 Apple Park 附近，改不了城市。

原因：模拟器默认位置是固定的，CLLocationManager拿到的是模拟位置，不是真实 GPS。很多同学以为是自己代码写错了，排查半天发现locality一直返回 "Cupertino"，其实是模拟器在捣乱。

解决：需要手动设定模拟位置。在模拟器菜单栏选择 Features -> Location -> Custom Location，输入你所在城市的经纬度；或者用 Car Play 列表里预设的城市。更省事的做法是直接换真机测试，真机定位行为才能代表用户真实环境。写代码时也可以在调试模式下写死一个城市名，方便快速验证 UI，不必每次都触发定位。

5.2 接口是 HTTP，被 ATS 拦成一片空白

现象：模拟器里请求天气接口，控制台报错 "App Transport Security policy requires the use of a secure connection"，请求返回 nil，界面一直是加载中。

原因：iOS 默认只允许 HTTPS 连接，如果你的调研接口没有配置 HTTPS（很多免费接口是 HTTP），请求会被系统直接拒掉。这不是代码逻辑问题，是网络传输层的安全策略。

解决：优先换一个支持 HTTPS 的接口。你可以在 Info.plist 里加NSAppTransportSecurity的NSAllowsArbitraryLoads临时放开限制，但这样上架审核有风险，而且行为不严谨。退一步的合法做法是只对特定域名开启NSExceptionDomains，但我的建议是直接用 HTTPS，这是 2024 年之后的最低要求。这条坑在综述调研阶段就应该标出来，凡是只支持 HTTP 的接口，直接不进对比表。

5.3 免费接口限流：热榜数据变成了「暂无数据」

现象：App 刚跑通时一切正常，多点了十几下刷新，突然所有请求都返回错误或空数据，界面出现「暂无数据」。

原因：免费天气接口通常有速率限制，比如分钟级最多请求 60 次。你在模拟器里反复触发请求，很容易就把配额打光了。

解决：缓存策略必须更快生效。除了上一章的缓存之外，UI 上应该做「刷新冷却」——用户点击刷新后，至少在 10 秒内不允许再点。代码实现上可以用一个时间戳记录上次请求时间，够不到间隔就返回缓存数据。这个机制写进综述里就是很实打实的「可靠性设计」。另外，调接口时务必开启日志，把返回的 HTTP 状态码和 body 都打出来，否则限流返回的错误会被你误当成合同数据。

5.4 SwiftUI 预览崩溃，真机却正常

现象：用 Xcode 的 Preview 预览界面，每次加载都转圈很久，有时候直接崩掉；但运行到真机上是好的。

原因：SwiftUI 预览是在独立进程里运行的，它没有你的 App 的启动流程初始化，网络层和定位在预览进程里也可能处于异常状态。比如你的视图onAppear里直接发网络请求，预览进程会卡在请求等待上，超时后崩溃。

解决：给预览提供 mock 数据。在视图初始化的参数里允许外部传入WeatherViewModel，预览时用一个「假数据 ViewModel」，运行到真机时用真实 ViewModel，互不干扰。另外一个技巧是在init里判断#if DEBUG且 UITest 或预览环境下禁用真实网络，这个做法不算优雅，但排查速度快。记住一条经验：预览只负责看 UI，不负责跑逻辑。

5.5 图标和启动屏问题：一整屏白屏或图标变形

现象：在手机上安装 App 后，桌面图标显示成一团黑/白，或者打开 App 后首屏白屏几秒钟。

原因：缺少需要的图标文件尺寸，或者没有设置启动屏。iOS 从某个版本起对启动屏的要求是「提供一张启动图或用 SwiftUI 的启动屏配置」，如果你没设置，系统会按默认尺寸适配，出现白屏。网上下载的图标文件（ios 图标文件）经常尺寸不全，只放了最大尺寸，系统缩放后失真。

解决：用 Xcode 的 Assets.xcassets 里的 AppIcon 占位符，把对应尺寸的图片拖进格子。不要在线生成一个「万能图标」就完事，至少提供180x180和1024x1024两个关键尺寸。启动屏直接用 SwiftUI 的Canvas配置或 LaunchScreen.storyboard，内容留白即可，不要放主界面的截图，因为启动屏一旦包含真实界面截图，审核容易被判「误导用户」。这条坑看起来低级，但我在不少毕设项目里见过，答辩现场打开老师的手机，桌面图标明显发虚，第一印象就差了。

6. 答辩前的小白验证：自动化测试、上架前置检查，和一篇「能查账」的综述

原型跑完、坑也踩完，接下来是「让老师相信你真的做出来了」的阶段。我的习惯是：不急着美化界面，先写三条自动化用例。Xcode 的 UI 测试（XCTest）能模拟用户点击，打开 App、等待定位、看到温度数字、切换到搜索城市，这四条路径能跑通，比任何截图都可信。加一组逻辑测试覆盖CacheManager——比如「缓存过 30 分钟后读出来的数据是旧数据」这个断言，在答辩时直接演示，效果比 PPT 里的流程图好得多。这就是把 ios 自动化 用在刀刃上。

上架流程如果你是第一次提交，至少要提前两周做前置检查：Apple Developer 账号、App ID 申请、签名证书（Certificate）、描述文件（Provisioning Profile）。不要试图在答辩前一天晚上完成签名打包，证书生成和审核有等待时间，不可控。图标尺寸、隐私权限文案、启动屏这三项是最常见的审核拒绝理由，也就是我们前面踩过的坑，先把这三个钉子拔掉再提审。

最后回到文献综述本身。我见过很多综述写成了「国外研究现状 + 国内研究现状」的空架子，和代码毫无关联。我的教训是：把综述当成「开发账本」，每个关键决策后面都补一句「因此本设计选择…」。当你从头到尾能回答「为什么用 SwiftUI」「为什么选这个接口」「缓存为什么设 30 分钟」时，你的论文和代码就是自洽的。这时候哪怕功能稍微糙一点，老师也知道你是想清楚才动手的，而不是抄了个 Demo 强行包装。这篇路线走下来，天气 App 就不再只是「图书馆里的一篇 doc 文档标题」，而是你手里一个能演示、能讲、能上线的小产品。希望帮到你。

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