企业官网建设流程全解析

先问个实在问题：你手里可能正有一台鸿蒙手机或者开发板，想尽快跑通“鸿蒙+跨端框架”这条路，网上资料又多又碎，今天跟着这个教程装好环境，明天跟着那个教程写了个计数器，但一落到自己的应用场景就发懵。如果你处在这样一个状态，这篇“Flutter学习day 1、变量与基本类型”就是给你准备的。我会把Dart语言里最基础的变量声明、类型系统和一套完整的智能家居监控模型串在一起，让你第一天学的东西直接变成能跑、能看、能扩展的代码。学完之后，你至少能独立写出一个“设备状态监控”的小模块，并且理解为什么鸿蒙生态下跨端框架Flutter值得投入时间。

这套内容不需要你有任何Flutter或Dart基础，只要碰过任意一门编程语言就够了。我会尽量用做智能家居监控时的真实业务来讲解，避免那种“定义一个变量a，赋值1，打印a”式的无效学习。下面直接进入正题。

1. 内容整体设计与思路拆解

1.1 为什么用智能家居监控模型来学变量与基本类型

很多教程讲“变量与基本类型”喜欢用和学生成绩、员工工资相关的例子，抽象、无感、记不住。我做技术分享的习惯是：把语言基础知识点“绑”到一个具体业务上，让每个知识点都有落点。智能家居监控模型特别适合做这个切入点，原因有三个。

第一，智能家居的数据天然就是多种基本类型的集合。设备ID是字符串，温度是浮点数，电量是整数，在线状态是布尔值，报警记录是列表，设备配置信息是映射表。一套模型学下来，Dart的核心类型基本全都能碰到，而且每个类型都能对应到真实的传感器或业务对象，理解成本比纯示例低得多。

第二，智能家居是鸿蒙生态里非常典型的应用场景——手机端要监控，平板端要看板，车机端也要看，未来还有PC端。这种“多端都要用”的需求，恰恰是跨端框架Flutter最擅长的领域。你第一天学的变量和类型，到了第二天写UI、第三天接状态管理，全部都会反复用到。这个学习路径不是绕路，而是直达目标的最短路径。

第三，从变量声明到类型选择，再到数据结构组织，这个模型可以做得非常完整——单房间监控、多房间对比、报警列表、设备画像，复杂度可以逐步升级。也就是说，你学的不只是语法，而是一整套可演进的代码骨架，这对新人后期成长很重要。

1.2 鸿蒙生态下为什么值得走Flutter这条路

聊这个话题前先说个背景：鸿蒙系统本身有自家的开发框架，但跨端框架Flutter在鸿蒙生态里已经跑通了，很多团队把它作为多端一致性的解决方案。做这个选择的逻辑并不复杂——一套Dart代码，既能跑在Android和iOS上，又能通过适配层跑在鸿蒙上，对中小团队来说，人力成本优势极其明显。

有人会担心：“那直接用鸿蒙原生不是更可靠吗？”这个问题得分场景。如果你的业务深度绑定鸿蒙系统能力，比如要用系统级的分布式软总线做多设备协同，那原生开发确实更合适。但如果你的核心业务是“一套界面+一套逻辑”铺到多个平台，Flutter的跨端优势就体现出来了，尤其是智能家居监控这种以UI展示和数据刷新为主的应用，Flutter的渲染性能完全撑得住。

再往深一层说，学习Flutter不等于抛弃鸿蒙原生能力。实际工程里两者完全可以配合：Flutter负责界面渲染和业务逻辑，鸿蒙原生负责系统底层能力调用，中间通过平台通道通信。所以“学Flutter”和“做鸿蒙开发”并不是二选一的关系，而是一条兼顾效率与深度的折中路线。

1.3 第一天学习目标的合理切分

我会把Day 1的内容限制在一个非常克制的范围内：变量声明方式、基本类型、类型转换、空安全基础，最后落到一个智能家居监控模型的小实战。为什么不一天讲完所有语法？因为Dart和Flutter的语法面很广，函数、类、异步、泛型、集合操作，哪个拎出来都够学一天。第一天的任务应该是把“类型思维”建立起来——知道什么数据用什么类型装，什么样子的变量该怎么声明，这个底子打不牢，后面全是空中楼阁。

所以这篇分享的定位很明确：不是API手册，不是语法大全，而是一堂“变量与类型的思维课+一段可运行的业务代码”。掌握了这套内容，你可以直接开始看Flutter的Widget教程，里面所有状态变量的声明你都能看懂了。

2. 核心细节解析与实操要点

2.1 变量声明：var、final、const到底怎么选

Dart里声明变量有几种方式，新手很容易全部都用var去写，代码也能跑，但工程性和可读性会很差。我们从智能家居场景出发，逐个看它们的使用边界。

var是“类型推断”声明，编译器会根据初始值自动推断变量类型。比如：

var deviceName = '客厅温湿度传感器';

这里deviceName会被推断为String类型。需要特别注意，Dart是强类型语言，一旦推断完成，这个变量的类型就固定了，不能再赋一个int值给它。很多人从JavaScript转过来，以为var是动态类型，这是第一天最容易踩的坑。

final是“运行时常量”声明，它表示变量只能被赋值一次。final变量可以在运行时才确定值，比如从接口读取的设备ID：

final deviceId = getDeviceIdFromServer();

这一行执行完之后，deviceId就不能再被重新赋值了。在智能家居模型里，设备ID、序列号、创建时间这类字段都应该用final，因为它们本质上不会被修改。

const是“编译期常量”声明，比final更严格。const变量的值必须在编译期间就确定，直接写死的那种。适合存放配置类的固定值：

const maxAlertCount = 20; const warningTemperature = 28.0;

报警上限阈值这种，代码写死、编译期就知道值、永远不变，用const是最合适的。使用const还有一个好处——多个地方引用同一个const对象时，Dart会复用同一个实例，省内存，这在长列表渲染时能体现出来。

比如在温度报警阈值这块的写法，我会这么组织：

const double highTempWarning = 30.0; const double lowTempWarning = 10.0;

这两个值不涉及网络请求、不依赖用户输入，就是纯配置，编译期确定，所以用const。而设备列表是运行时从服务端拉取的，必须先定义为空列表再后续填充，这种就用var或者明确的List类型。

2.2 基本类型全景：从温度读数到设备状态

Dart的基本类型和Java、Kotlin这类语言比较接近，讲起来不费劲。关键是每个类型能对应到智能家居的哪些业务数据上，我们把这个映射关系建好，记忆就不会乱。

int类型，整数。传感器电量百分比、报警次数、设备固件版本号（如果按数字处理的话）、房间编号，这些都可以用int。

double类型，浮点数。温度、湿度、PM2.5浓度、电压值、功率，这些带小数的传感器读数全部用double。有一点要提醒：int和double在Dart里都继承自num类型，但两者之间没有隐式转换，比如下面这个写法是错的：

int powerPercent = 86; double voltage = powerPercent; // 编译报错

因为Dart强调整类型的显式转换，不搞隐式给类型“放宽”那一套。正确写法是：

double voltage = powerPercent.toDouble();

反过来也一样，从double转int必须调用toInt()，截断小数部分。

String类型，字符串。设备名称、设备ID、房间名称、通信协议、固件版本字符串，都是String。Dart的字符串插值非常实用，直接用美元符号加大括号就能嵌入变量，比用加号拼接简洁太多：

String roomName = '客厅'; String report = '$roomName当前温度是${temperature}度';

bool类型，布尔值。设备在线状态、开关状态、报警使能开关、强电异常标记，都用bool表示。从传感器网络里拿到on/off、1/0这类值时要显式转换成bool，Dart没有自动转换逻辑，0和1不会被当成false和true。

List类型，有序集合。传感器历史读数序列、报警记录清单、房间设备列表。泛型参数可以限定元素类型，比如List 只能装double，装String会报错。这个约束能力在业务开发中极其重要，等于编译器帮你做了数据校验。

Map类型，键值映射。设备信息字典、房间配置表、上报数据包格式。比如采集到一组来自设备的数据包，用Map<String, dynamic>来解析是很常见的做法，key是字段名，value是动态值，后续再逐字段转成强类型。

Set类型，唯一集合。设备标签、去重后的告警类型集合。用Set可以自动去重，比如同一台设备可能上报多条通知，用Set收集消息ID就能天然过滤重复项。

2.3 空安全：第一天就要养成的防御习惯

Dart从2.12开始强制开启空安全（null safety），这可能是和很多其他语言最大的不同点。在Flutter里，默认所有普通类型变量都不能赋值为null，除非你显式地在类型后面加一个问号。

以设备状态为例：

String? deviceName; double? lastReportTemperature;

这两个变量可能暂时没有任何数据，比如设备还没上报过数据，温度值就是缺失的。加了问号后，这个变量允许为null，后续使用时就必须做判空处理，否则编译器直接报错。很多新人第一天写Flutter就被Untitled的null报错吓到，其实这是语言在帮你堵漏洞。

用null安全有一个好处：代码里能明确表达“这里可能有空值”的意图。比如在判断报警的时候：

double? lastTemperature; if (lastTemperature != null && lastTemperature > 30.0) { // 才有资格进入报警判断 }

注意第2章的重点是变量和类型的基础用法，这一节的空安全实际上也是变量声明的关键环节，因为它直接决定了变量能不能为null、怎么取值。在智能家居场景里，远程设备离线、传感器未返回数据、接口超时等情况都会产生空值，空安全机制会在编译阶段把这些风险点暴露出来，而不是等到线上运行才炸。

提示：不要把空安全理解成“写起来麻烦”。它是在编译期强迫你思考“这个值真的可能为空吗”，从源头上消灭了空指针这一大类Bug。等你写多了，你会发现这套机制比Java的空指针异常友好太多。

2.4 类型转换与判断：数据清洗的核心环节

智能家居设备上报的数据，经常不是规规矩矩的double或int，尤其是经过网络传输、数据库读写后，数值可能会以字符串形式传来。比如一条设备消息里，“温度”字段可能是字符串“23.5”，甚至可能是“23.5℃”这种带单位的脏数据。这时候就用到解析和转换。

常用转换方法如下：

String rawValue = '23.5'; double temperature = double.parse(rawValue); int readCount = int.parse('42'); String formatted = temperature.toStringAsFixed(1);

double.tryParse和int.tryParse是更安全的解析方式——解析失败时返回null，而不是抛出异常。在监控模型里这就是标准配置，因为设备数据不可能保证100%干净：

String? rawTemp = deviceMessage['temp'] as String?; double? temperature = double.tryParse(rawTemp ?? ''); if (temperature == null) { // 上报数据格式异常，走异常处理逻辑 }

注意第一行代码用了一个as String?的强转操作。这里需要补充一下as和is的区别——is用于类型判断，as用于类型强转。对于无法确定类型的动态值（比如Map里的dynamic值），接收时必须显式处理类型，不能依赖隐式转换。

3. 实操过程与核心环节实现

3.1 搭建智能家居监控模型的项目骨架

先创建模型的数据结构。我建议第一天就按“传感器实体类+监控模型类”两层结构来做，不急着写UI，先把数据层跑通。

新建一个传感器数据的实体类，代码如下：

class SensorData { final String deviceId; final String deviceName; final String roomName; final double temperature; final double humidity; final int batteryLevel; final bool isOnline; final DateTime lastUpdate; SensorData({ required this.deviceId, required this.deviceName, required this.roomName, required this.temperature, required this.humidity, required this.batteryLevel, required this.isOnline, required this.lastUpdate, }); }

这段代码是第二天的内容预热，但今天你能看到变量类型在这里的落地：deviceId用final String，因为设备ID不可变；temperature用double，因为是传感器浮点值；isOnline用bool，表达在线状态；lastUpdate是DateTime类型，这个也是Dart内置类型，专门处理时间。

再定义一个监控模型类，负责模拟生成设备数据和报警判断：

class HomeMonitoringModel { final List<SensorData> _sensors = []; void addSensor(SensorData sensor) { _sensors.add(sensor); } List<SensorData> get onlineSensors => _sensors.where((sensor) => sensor.isOnline).toList(); List<SensorData> get offlineSensors => _sensors.where((sensor) => !sensor.isOnline).toList(); List<SensorData> get highTemperatureSensors => _sensors.where((sensor) => sensor.temperature > 28.0).toList(); }

这里用到了List的where方法做条件筛选，这是Day 1最后的小小延伸，但你只需要理解为“从传感器列表里过滤符合条件的数据”即可。onlineSensors、offlineSensors、highTemperatureSensors是三个计算属性，分别得到在线设备、离线设备、高温报警设备，这是智能家居监控里面最典型的三个视图。

3.2 模拟一段智能家居上报流程

有了模型，我们要模拟实际设备上报。这里不会真去接MQTT或鸿蒙软总线，而是先用代码构建设备、填充数据，再执行查询逻辑。但数据结构和流程与真实业务保持一致，你后面接真实数据源时可以直接替换。

void main() { var monitor = HomeMonitoringModel(); // 客厅温湿度传感器 final livingRoomSensor = SensorData( deviceId: 'SN001', deviceName: '客厅温湿度传感器', roomName: '客厅', temperature: 26.5, humidity: 65.2, batteryLevel: 87, isOnline: true, lastUpdate: DateTime.now(), ); // 卧室空气质量传感器 final bedroomSensor = SensorData( deviceId: 'SN002', deviceName: '卧室空气质量传感器', roomName: '卧室', temperature: 29.8, humidity: 58.1, batteryLevel: 32, isOnline: true, lastUpdate: DateTime.now(), ); // 厨房烟雾传感器（已离线） final kitchenSensor = SensorData( deviceId: 'SN003', deviceName: '厨房烟雾传感器', roomName: '厨房', temperature: 30.5, humidity: 60.0, batteryLevel: 0, isOnline: false, lastUpdate: DateTime.now().subtract(Duration(hours: 5)), ); monitor.addSensor(livingRoomSensor); monitor.addSensor(bedroomSensor); monitor.addSensor(kitchenSensor); print('在线设备数量: ${monitor.onlineSensors.length}'); print('离线设备数量: ${monitor.offlineSensors.length}'); final alerts = monitor.highTemperatureSensors; for (var sensor in alerts) { print('温度告警: ${sensor.deviceName} 当前${sensor.temperature}℃'); } }

跑完这段代码，控制台的输出会是三条信息：在线设备数量2、离线设备数量1、温度告警两条。别小看这个输出，背后已经把变量声明、final/const选择、List操作、字符串插值、bool判断、类型推断全部用上了。你第一天学的所有语法点在这十几行代码里都能找到落点。

3.3 引入Map类型管理更丰富的设备信息

实际智能家居项目里，传感器的字段远不止这些，还有固件版本、协议类型、安装日期、商户信息等等。如果都用实体类的字段去接，实体类会越来越臃肿。此时可以用Map来存储“扩展属性”，这也符合很多物联网平台上报数据的真实格式。

final extraInfo = <String, dynamic>{ 'firmwareVersion': '1.4.2', 'protocolType': 'MQTT', 'installDate': '2025-08-15', 'signalStrength': -61, 'isFactoryReset': false, };

这个Map<String, dynamic>是Flutter开发里出现频率极高的一种类型。String是key的数据类型，dynamic表示value可以是任意类型。注意dynamic并没有放弃类型安全——它在运行时依然会做类型检查，只是把检查推迟到了运行时而已。所以从Map里取出来的值，一般都要做一次显式转换，才能赋给强类型变量：

String firmwareVersion = extraInfo['firmwareVersion'] as String; int signalStrength = extraInfo['signalStrength'] as int;

如果实际值类型不匹配，运行时就会抛类型转换异常。这就是为什么从Map取值时必须确保数据来源可靠，或者用上一章提到的tryParse和安全性强转来兜底。

3.4 用const统一管理监控阈值

智能家居监控必然涉及大量配置阈值——高温报警线、低温报警线、湿度上下限、电量低报警线、PM2.5警戒值。这些值如果散落在业务代码里，后期调整极其痛苦。最佳实践是用const集中定义。

class MonitorConfig { static const double highTempAlert = 28.0; static const double lowTempAlert = 10.0; static const int lowBatteryAlert = 20; static const double highHumidityAlert = 75.0; static const double highPm25Alert = 120.0; }

static const的组合表示：这些常量属于类本身，不随实例变化，编译期值固定。在检测代码里直接引用MonitorConfig.highTempAlert，阅读性和可维护性都会显著提升。后面如果要根据季节调整阈值，比如夏天高温线调高到32度，只需要改这一处，所有引用它的地方都会同步更新。

这就是const在真实工程里的核心价值——它不仅是写不写得出来的问题，更是代码里“可配置性”的设计问题。

3.5 完整实战：智能家居环境预警模型

把上面的碎片整合成一个可运行的完整示例，模拟一套基础的“温度+湿度+电量”三合一预警。这个模型已经具备一个小型Demo的核心要素。

class EnvironmentMonitor { final String monitorId; final String location; final Map<String, SensorData> sensorMap; EnvironmentMonitor({ required this.monitorId, required this.location, required this.sensorMap, }); List<String> generateReport() { List<String> reports = []; sensorMap.forEach((deviceId, sensor) { if (!sensor.isOnline) { reports.add('${sensor.roomName} ${sensor.deviceName} 离线'); } else { if (sensor.temperature > MonitorConfig.highTempAlert) { reports.add('${sensor.roomName} 温度过高: ${sensor.temperature}℃'); } if (sensor.humidity > MonitorConfig.highHumidityAlert) { reports.add('${sensor.roomName} 湿度过高: ${sensor.humidity}%'); } if (sensor.batteryLevel < MonitorConfig.lowBatteryAlert) { reports.add('${sensor.roomName} 电量不足: ${sensor.batteryLevel}%'); } } }); return reports; } }

这段代码里的关键点在sensorMap.forEach——Map类型提供的遍历方法，参数是一个回调函数。Dart里函数是一等公民，可以把函数作为参数传递，这个特性在后面Flutter的UI回调里到处都是。第一天你不需要完全掌握函数的全部语法，只需要理解这个调用方式即可，后面的学习会越来越熟悉。

下面跑一遍：

void main() { final monitor = EnvironmentMonitor( monitorId: 'MON-HOME-001', location: '三室一厅住宅', sensorMap: { 'SN001': SensorData( deviceId: 'SN001', deviceName: '客厅温湿度传感器', roomName: '客厅', temperature: 27.2, humidity: 72.5, batteryLevel: 86, isOnline: true, lastUpdate: DateTime.now(), ), 'SN002': SensorData( deviceId: 'SN002', deviceName: '卧室空气质量传感器', roomName: '卧室', temperature: 32.1, humidity: 66.0, batteryLevel: 12, isOnline: true, lastUpdate: DateTime.now(), ), 'SN003': SensorData( deviceId: 'SN003', deviceName: '厨房烟雾传感器', roomName: '厨房', temperature: 24.0, humidity: 80.1, batteryLevel: 0, isOnline: false, lastUpdate: DateTime.now().subtract(Duration(hours: 5)), ), }, ); final reports = monitor.generateReport(); for (var report in reports) { print('【预警】$report'); } }

输出结果会是卧室温度过高、厨房湿度预警、厨房离线、卧室电量不足这几条，每条预警信息都是从变量判断出来的。这个模型虽然简单，但已经具备了真实监控系统的基本判警逻辑：状态检查、区间判断、阈值触发、结果汇总。后续要做的事情就是把它接上Flutter的界面层，用列表和卡片展示这些报告。

4. 常见问题与排查技巧实录

4.1 var声明的变量能改类型吗

这是一个高频疑问，尤其是有JavaScript背景的开发者会反复踩。Dart的var是类型推断，不是动态类型。下面这段代码会直接编译报错：

var temperature = 26.5; temperature = '高温'; // 报错：String无法赋给double

因为第一次赋值已经是double了，编译器会把temperature的类型锁定为double，后面赋String就违反了类型约束。同时，这也解释了为什么Dart适合做大型团队协作——编译器能帮你拦截掉大量“类型悄悄变化”导致的隐性Bug。

如果你确实需要一个既能存数字又能存字符串的变量，怎么办？用Object类型：

Object value = 26.5; value = '高温';

这个语法是合法的。但是我不建议在业务代码里这么用，因为Object类型让编译器失去了类型检查能力，所有本来能提前暴露的问题都会变成运行时报错。只有解析外部不可控数据、动态配置这类场景才适合放宽到Object/dynamic。

4.2 final和const到底差在哪

简单说：final是“运行时只能赋值一次”，const是“编译期值就已经确定”。同样声明一个变量，final的值可以来自函数调用、用户输入、网络请求，但const必须是字面量或由const表达式计算得来。

final currentTime = DateTime.now(); // 正确 const fixedTime = DateTime.now(); // 报错：DateTime.now()不是编译期常量 const maxCount = 100; // 正确 final deviceId = getRandomDeviceId(); // 正确，运行时才确定

还有一个容易忽略的点：const可以用在类级别，声明类的编译期常量，也就是前面MonitorConfig那种用法。final更常用在实例级别，表示“这个实例的字段一旦初始化就不再改变”。在智能家居模型里，传感器列表用final修饰，但列表里的内容可以增删，因为final限制的是“引用不能变”，而不是“对象内容不能变”。

4.3 空安全相关的异常和根治方法

第一天写完代码，你可能会遇到类似这样的报错：

A nullable value can't be assigned to a non-nullable variable type 'double'.

这个报错的含义非常明确：右边表达式的值可能为null，但左边变量的类型不允许null。解决办法分两步：先判断来源，如果是外部接口的字段，用能解析失败的解析方式（如double.tryParse）加上空判断；如果逻辑上确实允许为空，就显式声明为double?类型。

在实际项目里，我看到很多新人用兜底值一棒子打死——只要可能为空就直接赋个0或者-1。这种思路虽然绕过了编译器报错，但把“数据缺失”和“真实值是0”混为一谈，后续处理会出大问题。正确的思路是保留null语义，在需要的时候分支处理。比如温度传感器离线时lastTemperature为null，就比默认0要合理得多，因为0度可能触发低温报警，而null可以让逻辑直接跳过报警判断。

4.4 常见问题速查表

4.5 一段容易踩坑的浮点数输出问题

用double保存传感器数据时，比如：

double temperature = 26.699999999; // 实际请求回来的数据可能是这种“残缺值”

你直接插值打印时结果会出现一长串小数，这对用户界面很不友好。正确的做法是用toStringAsFixed控制精度。智能家居场景里一般保留1位小数就够用了：

double temperature = 26.699999999; String displayTemp = temperature.toStringAsFixed(1); print('$displayTemp℃'); // 输出 26.7℃

这个用法和Monet、ECharts里刻度显示逻辑一样——显示层的格式化问题不应该污染数据层的原始精度。传感器原始数据保持完整精度，展示时再格式化，是很干净的架构分界。第一天就把这个意识建立起来，后续做图表、做列表展示时会少踩很多坑。

5. 关键收获与下一步学习方向

5.1 今天真正学会的东西

不管你是完全零基础还是从别的语言转过来，今天这套内容至少建立了三个核心认知：第一，Dart的变量声明不是随便选个关键字就完事，var、final、const各有严格的适用场景，选对了代码的可读性和稳定性都会明显提升。第二，基本类型不是孤立的语法知识点，每个类型都对应着业务里具体的一类数据，用“温度是double、在线状态是bool、设备信息是Map”这种映射关系来学，记得又快又牢。第三，空安全是Dart为工程化而生的关键设计，以前在其他语言里常见的“空指针异常”在Dart里被提前到编译阶段拦截，这套机制虽然一开始会让人觉得拘束，但长期看是非常值得的投资。

5.2 和鸿蒙+Flutter实战之间还差几步

完成了今天的内容，你已经能看懂Flutter基础教程里80%的变量声明写法了。接下来建议的路径是这样的：先熟悉Widget树的概念，搞清楚StatelessWidget和StatefulWidget的区别——本质上，前者用final修饰全部数据，后者多了一个可变状态State，这正好呼应了今天学的final和var的选择问题。等你理解了状态管理，再回过头来看这个智能家居监控模型，会发现我们今天的SensorData类、EnvironmentMonitor类，直接就能作为Flutter页面的数据源，用ListView展示报警报告列表，用Card展示设备卡片。

从“学语法”到“写界面”之间，只需要两到三天的过渡时间，关键是你已经理解了数据是怎么定义、怎么流转、怎么判断的。这些底层逻辑一旦通了，界面上层就是纯粹的套路问题。

5.3 这套模型可以怎么扩展

我们目前做的是单个房间设备的监控模型，你可以发挥的方向很多。比如把SensorData扩展为支持更多传感器类型：PM2.5传感器、烟雾探测器、人体红外传感器、门窗磁传感器，每个类型的监控指标不一样，预警策略也不同。再比如引入时间序列——把SensorData变成一个读数的集合，这样就能在Flutter里画温度变化折线图、湿度变化曲线，那已经是Day 5之后的内容了。模型本身搭得好，后面接什么功能都不费力。

我个人在实际做项目时还有个体会：这套模型不只是给Flutter用的。以后如果你要给这个智能家居监控做云端同步、做小程序端，今天定义的这个实体结构和判警逻辑都可以复用。变量的类型设计、类的组织结构，这些跨端概念是所有平台通用的。打好这个底子，后面学什么框架都只是换一层皮，核心骨头是一样的。