企业官网建设流程全解析

做毕设选课题那会儿，不少同学一看到“STM32 + WiFi远程温控风扇”就直接劝退，觉得又要搞硬件又要写上位机，还得调试无线通信，听着就头大。但说实话，我把这个项目完整做下来之后最大的感受是：它本质上就是把三件事串在一起——测温度、传数据、控风扇。你只要把这条链路打通，整个系统的核心就立住了。剩下的所谓“远程”、“自动”，都是在链路之上加逻辑而已。这篇以我的实际踩坑经历为主线，把这个毕设从方案选型、硬件设计、下位机逻辑、上位机开发到调试排障的完整过程都拆开讲一遍，你照着这个思路走，至少能少走一半弯路。

这个系统能做什么？简单说就是：风扇可以根据环境温度自动调速，温度高了转快点，温度低了转慢点；同时你可以在手机上连上WiFi，远距离查看当前的温湿度数据，手动开关风扇、切换自动/手动模式。做出来之后可以放机房机柜散热、养殖箱通风、设备柜降温，也可以拿来说明书式的演示。适合的读者非常明确：电子类、嵌入式相关专业准备做软硬结合毕设的本科生，或者想快速上手STM32+WiFi物联网小项目的入门开发者。

1. 项目拆解：一个完整温控系统要解决哪些事

1.1 核心需求解析

先把需求拆成功能点，这个动作其实是整个项目的地基。很多同学一上来就画框图、买模块，结果做到一半发现硬件不够、逻辑打架、顺带还把时间耗在无谓的重构上。我建议你第一步先在纸上列清楚：系统到底要完成什么。

从这个项目标题“stm32 wifi远程温控风扇系统”来看，至少包含四个核心功能模块：

• 温度采集：实时读取环境温度，这是控制决策的依据。常见的传感器就是DHT11、DS18B20这类单总线或单线协议器件，采集到的数据要准确、稳定，否则后面的控制逻辑全是空中楼阁。
• 温控策略：根据温度自动调整风扇转速。这里牵扯到控制算法，最简单的是阈值控制加滞回，稍微好一点的是分段PWM调速，再做讲究点可以上PID。
• WiFi远程通信：把温度数据传到手机或电脑端，同时接收远程控制指令。ESP8266是绝对的主流方案，价格便宜、资料多、AT指令也好调。
• 手动与自动切换：远程控制分两种思路，一种是人直接指定风扇开关和转速，另一种是让人切换系统的运行模式，自动模式下由程序按温度决策。好的系统设计会同时保留这两种操作路径。

这四个功能全部打通，你的毕设主体就完成了。剩下的OLED显示、按键本地控制、LED状态指示都属于锦上添花，但要做到答辩时有亮点，这些细节通常还是得补上，因为老师看的不只是功能，还有你的工程完整性。

1.2 方案选型：为什么WiFi而不是蓝牙或ZigBee

很多同学在开题阶段会在无线方案上纠结，蓝牙模块便宜简单，ZigBee好像更物联网，LoRa听起来更高端。这里我要说句大实话：毕设场景下，WiFi方案是这个题目的最优解，没有之一。

原因有三。一是传输距离和穿透性适中——蓝牙在空旷环境也就十米上下，隔一堵墙就信号衰减得厉害，而WiFi覆盖整个宿舍、实验室没有问题，演示时你可以让手机站在几米十几米外控制，效果更直观。二是WiFi模块可以直接接入现有网络基础设施，不需要额外配网关或协调器，你做毕设不可能再去搭一套完整的网络协议栈。三是资料量和开发成本——ESP8266的AT固件成熟稳定，网上案例一抓一大把，哪怕你以前没接触过无线通信，照着资料调两天基本能跑通。

至于为什么不用ZigBee，核心原因是入网流程复杂且不透彻，答辩时老师很容易追问“你的网络拓扑是什么”“协调器怎么处理的”，你要是没搞透很容易翻车。LoRa就更没必要了，那是长距离低功耗场景，项目本身是室内近场控制，杀鸡用牛刀。

1.3 系统总体架构：数据是怎么流起来的

整个系统的数据链路其实非常清晰。先画一个逻辑通道：传感器把温度变成数字信号，STM32通过GPIO读取并做滤波处理，然后一方面把温度显示在本地OLED上，另一方面通过串口把数据打包发给ESP8266，ESP8266再以WiFi方式发送到处于同一局域网内的手机APP或者电脑上位机。反向链路同理，手机发指令给ESP8266，ESP8266通过串口把解析好的指令交给STM32，STM32根据指令切换控制模式或手动调节PWM输出占空比，进而改变风扇转速。

我这里特意强调“同一局域网内”——毕设演示场景下最稳妥的实现就是手机和ESP8266连接同一个路由器，模块作为TCP客户端主动连接运行在手机或者电脑上的TCP服务器APP。这套方案不依赖外部公网服务器，不受制于平台规则，调起来完全可控，演示时就算断网也能快速恢复。

2. 硬件设计要点：器件选型与电路连接

2.1 主控芯片：STM32家族怎么选

这个项目里面的“stm32”范围其实很宽，F103、F407、L4系列都能做，不同系列的区别主要体现在Flash、RAM容量和时钟频率上。但对这种温控风扇项目而言，F103C8T6绰绰有余，毫不夸张地说它的性能只用到了三成不到。

F103C8T6是Cortex-M3内核，72MHz主频，64KB Flash，20KB RAM，十几个GPIO够用，三个串口也够用（一个接WiFi、一个接调试、还有一个留着备用）。关键是这类最小系统板便宜，坏了也不心疼，配套的HAL库和标准库教程多到泛滥，遇到问题基本搜一下就有答案。

当然也有同学想用ESP32做主控，说它本身就带WiFi蓝牙，不需要外挂模块。这个思路在工程上确实简化了硬件，但要注意选题是“stm32”项目，标题里已经定死了主控平台，如果换成ESP32，整个毕设的方向就跑偏了。所以还是坚持STM32+ESP8266的组合，让MCU专心做控制和采集，WiFi模块专管通信，分工明确，答辩时也能说清楚每个器件的职责。

2.2 温度传感器选型：DHT11、DHT22还是DS18B20

温度传感器是温控系统的“眼睛”，选型直接影响控制精度和答辩观感。三种常见传感器的对比如下：

我的建议很直接：预算允许就直接上DHT22，温湿度都能读，精度也拿得出手，答辩时老师问“为什么选它”你有话说。如果经费特别紧张，DHT11也能跑，但你要有心理准备——它测得的温度跳动比较明显，做出来曲线不好看，控制逻辑如果不够稳，会出现风扇转速频繁跳变的情况，演示效果打折扣。

DS18B20的强项是测温精度和探头引线灵活性，搞个防水探头能伸进设备内部测实际发热点，这是DHT系列做不到的。如果想做双传感器对比（环境温度+热源温度），那DS18B20和DHT22组合是个很高级的搭配，论文内容和答辩素材会丰满很多。

2.3 WiFi模块：ESP8266的两种玩法

ESP8266是这套系统里绕不开的模块，市面上常见的封装有ESP-01S和ESP-12F。ESP-01S体积小、引脚少、价格最便宜，但板载天线增益一般，且模块只有两个可用的GPIO，扩展性差，更适合纯透传用途；ESP-12F引出引脚更多、板载PCB天线、Flash更大，如果你后面想直接在ESP8266上跑MicroPython或自定义固件，选它更从容。

模块的玩法分两种。一种是直接刷AT固件，这是最简单、也最适合毕设的路径：STM32通过串口给ESP8266发AT指令，比如“AT+CIPSTART”建立TCP连接，“AT+CIPSEND”发送数据。MCU只负责字符串拼接和解析，WiFi协议栈全部封装在模块里，开发工作量集中在串口通信上。另一种是把ESP8266当成独立节点，用Arduino或MicroPython单独编程，这样就需要在两颗芯片上分别写代码，上下位机联动时还要考虑两边的握手协议，复杂度明显上了一个台阶。

毕设场景我真的推荐第一种。你省下来的时间精力可以投入到控制算法、界面设计、文档撰写这些更“出分”的地方。只要在论文里清楚解释AT指令的流程和串口数据帧格式，老师不会觉得你取巧，反而认为你有工程思维。

2.4 风扇驱动：MOS管还是电机驱动模块

风扇驱动是很多新手容易翻车的地方。STM32的GPIO输出电流只有几毫安，电压是3.3V，直接带动一个额定5V/12V的风扇根本不可能，必须加驱动电路。这里有两类常见选择。

一类是逻辑电平N沟道MOS管，比如AO3400，这是我最推荐的方案。它的导通电阻很低，开关速度快，3.3V的栅极电压就能让它完全导通，非常适合做PWM调速。电路连接也简单：MOS管栅极串一个100Ω电阻接STM32的PWM引脚，源极接地，漏极接风扇负极，风扇正极接电源正极，再在风扇两端并联一个续流二极管（1N5819）吸收反向电动势，防止关断瞬间电压尖峰打坏管子或MCU。这套方案成本不到一块钱，满载电流几安培都没问题。

另一类是L298N电机驱动模块，常见于小车项目，可以直接驱动直流电机，也能驱动风扇。但用在这里有几个问题：模块体积大、压降明显（内部是三极管H桥，导通时有压降），发热比较可观，而且价格是MOS管方案的十倍往上。它的优势是接口傻瓜化、不容易烧，适合完全没焊过电路的同学。

如果风扇是5V小功率（比如电脑机箱风扇、3D打印机散热风扇），MOS管方案稳如老狗；如果风扇是12V大功率（比如服务器风扇），那你得额外配12V电源，并且MOS管选耐压更高、电流更大的型号，比如AO3400换成IRLZ44N这种。选型逻辑不复杂：先看风扇额定电压电流，再反推MOS管参数。

2.5 供电与硬件接线图整理

做硬件第一步就是把各模块的电源需求列清楚。STM32最小系统板一般通过USB或者AMS1117稳压到3.3V供电，ESP8266模块本身支持3.3V供电，但它启动瞬间电流能到300mA以上，如果用开发板上的3.3V LDO直接喂它，很容易出现电压跌落导致模块反复重启。最稳妥的做法是ESP8266单独用一颗AMS1117-3.3稳压芯片供电，输入5V，输出给模块。风扇用5V独立供电，如果你的5V电源电流输出足够大（2A以上），OLED和其他外设也可以共用这路5V再稳压。

典型的接线关系可以归纳成一张速查表：

这里有个细节：USART2的PA2/PA3和很多下载器冲突概率低，但如果你用串口1（PA9/PA10）调试打印，建议WiFi接串口2，避免调试信息和WiFi数据混在同一个串口里，不然排查问题时会非常痛苦。

3. 下位机软件设计：STM32端怎么做才优雅

3.1 代码工程结构与初始化流程

下位机软件开发我建议直接用STM32CubeMX生成HAL库工程，图形化配置引脚和时钟，然后自己在用户代码区写逻辑。比网上那些老式标准库例程清晰太多，也便于答辩时展示“我会使用HAL库”。

时钟树方面，F103C8T6直接用HSE外部8M晶振倍频到72MHz，APB2总线上的定时器时钟是72MHz，PWM频率设置就靠这个基准。DHT22的数据引脚配置成开漏输出带上拉，这个细节很关键——DHT22是单总线协议，主机和传感器都要能拉低总线，开漏模式配合外部上拉电阻才能实现双向通信。OLED和ESP8266的串口按常规配置就好。

初始化流程大致是：HAL_Init -> SystemClock_Config -> GPIO初始化 -> 串口1（调试）初始化 -> 串口2（WiFi）DMA初始化 -> TIM2 PWM通道初始化 -> OLED初始化 -> DHT22首次读取，主循环再执行状态机。建议把整个逻辑拆成“采集-处理-输出”三个子模块，每个模块一个函数，这样后期扩展和调试都有清晰索引。

3.2 温度采集与滤波：传感器数据不能直接用

DHT22的读取时序网上有很多参考代码，核心逻辑就是主机先拉低总线至少1ms发起开始信号，然后释放总线，传感器应答后连续输出40位数据，其中湿度高字节、湿度低字节、温度高字节、温度低字节、校验字节各占8位。校验是低八位等于前四个字节相加之和，这一步一定要做校验，否则通信偶尔错一位就会导致温度突变到离谱值。

我踩过的坑是数据突变，明明室温25度，偶尔读出来80多度，风扇直接全速转起来，吓一跳。原因就是单总线时序受中断影响，读bit时一个中断插入，时间窗口就崩了。解决办法有几个层次：

• 最基础的是读数据期间关闭中断，保证时序稳定；
• 更进一步是加软件滤波，比如连续读5次，去掉最大最小值再取平均；
• 最高级一点是加入合理性判断，读取值超过物理范围（比如温度在-40~80之外）就丢弃，用上一次的有效值代替。

实际项目里我是“超限剔除+滑动平均”组合着用：每次读5帧，先做校验通过和范围判断，剩下的值再进一个环形缓冲区，算最近10次有效读数的平均值作为控制输入。这样下来温度曲线平滑多了，风扇也不会因为瞬时波动而抽风。

3.3 控制策略：阈值滞回、分段调速、还是PID

控制策略是整个下位机软件的灵魂，也是答辩时老师最爱深挖的部分。这里我分三个层次讲，你根据自己的时间和技术水平选。

第一层，阈值滞回控制。设定温度阈值比如28℃，超过28℃开风扇，低于28℃关风扇。但纯阈值有个老问题——“抖动”：室温徘徊在28℃附近时，风扇会反复开关，继电器咔哒咔哒响，演示现场非常尴尬。解决办法是引入滞回：开启温度设成28℃，关闭温度设成24℃，也就是说温度升到28以上才开启，降到24以下才关闭，中间的4℃区间系统维持当前状态不变。这种方式简单可靠，适合做基础功能。

第二层，分段PWM调速。风扇不一定只开关两态，转速可以按温度梯度分几档。比如低于25℃停转，25~28℃转30%，28~31℃转60%，高于31℃全速。每一档之间做滞回处理，避免在边界处反复跳动。这种方式视觉效果最好，演示时用吹风机加热，能清楚看到转速逐步上升，观众和答辩老师都能直观感受到“温控”在起作用。

第三层，闭环PID。PID在温度控制场景里的尴尬是：温度是慢变量，PWM输出是快变量，系统存在明显的纯滞后，PID参数没调好就会超调严重。但你不用把PID调到工业级稳定，只要在论文里说明“采用位置式PID，输出限幅，通过实验整定Kp=xx、Ki=xx、Kd=xx，系统稳态误差控制在±0.5℃以内”，同时用滞回逻辑做底保，就已经非常有说服力了。

我的最终方案是“分段PWM为主，串口下发PID参数为辅”。默认跑分段调速逻辑，稳定好讲；又预留了PID函数接口，论文里能力展示这一块就有了素材，两全其美。

3.4 WiFi通信协议设计：串口数据帧怎么定

很多同学做WiFi项目卡在一个点：STM32和ESP8266之间的串口数据没格式，发出来一堆字符串，程序完全没法可靠解析。所以通信协议一定要在写代码之前先设计好。

我用的协议是简单可靠的ASCII帧格式，形如：

$TEMP,26.50,HUM,55.30,MODE,AUTO,SPEED,65,CHK,8F#

字段含义依次是：起始符$、传感器数据标识、温度值、湿度标识、湿度值、模式标识（AUTO/MANUAL）、转速百分比标识、实际PWM占空比、校验和标识、8F是前面所有字段ASCII码累加和的低字节十六进制表示、结束符#。

为什么不用JSON？STM32解析JSON要引入第三方库，片内资源富余没问题，但答辩时你想把实现讲清楚就会多费不少口舌。自定义ASCII帧一眼就能看懂格式，学生写解析代码不过二十行，老师检查代码也轻松。

STM32端接收ESP8266转发来的指令，同样按帧解析。比如手机下发：

$CMD,MODE,MANUAL,SPEED,75,CHK,XX#

MCU收到后先找起始符$和结束符#，然后逐段比对标识符，最后校验CHK值，校验通过才执行。无效帧直接丢弃并计数，连续收到多个无效帧才报通信异常。这里有个重要心得：校验和不是可选项，是必选项。没有校验时WiFi环境里偶发一个字节错误，系统就误动作，有了校验码，错误帧全都被拦截在门外。

3.5 核心代码片段参考

下面给出两段最核心的代码，一段是PWM调速输出，一段是协议解析主循环。代码风格仅供参考，研发时结合你自己的工程结构调整。

PWM输出函数：

// 设置风扇转速，speed范围为0~100 void Fan_SetSpeed(uint8_t speed) { uint16_t ccr = (uint16_t)(speed * 999 / 100); // TIM2 ARR=999，占空比=CCR/(ARR+1) __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_2, ccr); } // 手动模式 void Fan_ManualControl(uint8_t speed) { Fan_SetSpeed(speed); Send_Status_Message(); // 广播当前状态给WiFi模块 } // 自动模式：依据温度决定转速 void Fan_AutoControl(float temperature) { uint8_t speed = 0; if (temperature < 25.0f) speed = 0; else if (temperature < 28.0f) speed = 30; else if (temperature < 31.0f) speed = 60; else speed = 100; Fan_SetSpeed(speed); }

串口中断接收解析（简化示意）：

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart == &huart2) { // 把字节存入环形缓冲区 RingBuffer_Write(&wifi_rb, (uint8_t*)&rx_data, 1); HAL_UART_Receive_IT(&huart2, &rx_data, 1); // 在后台任务中调用 FrameParser_Poll(&wifi_rb); } }

这里串口接收用“每收一个字节触发中断+环形缓冲”的方式，比一次接收固定长度要健壮得多，因为WiFi数据什么时候来、来多少都是不确定的，固定长度接收很容易粘包拆包。

4. 上位机与远程控制端：手机APP和PC上位机怎么落地

4.1 通信模式：STATION模式与TCP客户端

远程控制的应用端有两种常见架构。第一种是做TCP服务器端：ESP8266连上路由器后，用AT指令直接开启TCP Server监听端口，手机APP作为客户端主动连它。STM32端只要通过串口发AT指令，服务器逻辑完全由模块处理。这种方式不用在电脑上跑额外服务，适合演示时直接把电脑或手机当客户端。第二种是做TCP客户端：ESP8266通过AT指令主动连接PC上的服务器软件，PC端用Python或C#写个监听socket，收数据显示和下发控制。

我更推荐第一种的变体：ESP8266连接家庭路由器（STA模式），开启TCP Server，手机APP作为TCP Client去连接模块的IP地址。这样模块的IP固定（可以是路由器DHCP分配的，也可以手动设置静态IP），演示时打开APP输入IP就能连上，不依赖外部任何主机，最有“产品”的感觉。

AT指令序列就三段：

AT+CWMODE=1 // 设置为Station模式 AT+CWJAP="SSID","密码" // 连接路由器 AT+CIPMUX=1 // 开启多连接 AT+CIPSERVER=1,8080 // 启动TCP服务器，端口8080

花几块钱买个树莓派无线路由器网段隔离也可以，但普通路由器足够，不用额外折腾。

4.2 Android手机APP的快速实现思路

Android客户端可以用Android Studio写一个最简的TCP工具型APP，界面就三个元素：IP输入框、连接/断开按钮、状态与数据显示区，再往下是模式切换和转速滑杆。

核心代码逻辑不复杂，主线程不能直接做网络操作，所以开一个子线程跑Socket。建立连接后，写一个循环接收InputStream里的数据，把收到的温湿度字符串解析出来，通过Handler或者LiveData推送到UI更新。发送指令时直接在主界面按钮的点击事件里调用OutputStream.write()，把自定义协议帧写进socket。

技术要点有三个：一是APP端记得加网络权限，WiFi下Android 6.0以上还需要申请本地网络权限；二是保持心跳，ESP8266这个TCP Server有个特点，客户端长时间不发送数据，连接可能被路由器或模块内部机制回收，最好的办法是APP每5秒发一个空的心跳包或者查询状态帧，模块收到后返回状态，双方都活跃；三是APP掉线重连机制，模块重启后TCP Server恢复，但旧连接已失效，APP要能自动循环重连，不然演示时一旦断线就很被动。

如果你不想写Android原生，一个替代方案是用Python写PC上位机，PyQt5加socket库，几百行就能做一个带界面的控制台，开发周期更短，调试也更简单。我用后者撑完了前期联调，后面才补的Android端，先跑通协议再美化界面，这个顺序很推荐。

4.3 本地手动控制：按键与OLED人机交互

作为毕设，系统不能只靠手机远程控制，本地按键和显示是必须有的。否则万一演示时手机连不上，整个系统就瘫痪了。本地交互模块给出最低限度的功能：按键切换自动/手动模式，手动模式下按键调整转速；OLED实时显示温度湿度、当前模式、PWM占空比。

这里我用一个单按键方案：短按切换自动/手动，长按进入手动加速，双击进入手动减速。按键处理用状态机+定时器扫描，做好消抖处理，不然GPIO毛刺会导致模式乱跳。

OLED显示建议分两屏：第一屏显示温湿度和风扇转速百分比；第二屏显示WiFi连接状态和模块IP地址，方便演示时直接照着IP填APP。两屏通过按键切换，信息展示完整又省地方。

4.4 远程控制与自动控制的切换逻辑

系统必须定义清楚“手机控制”和“自动温控”的优先级关系。我的设计如下：开机进入自动模式，温度主导PWM输出；手机发来手动模式指令后，切到手动模式，此时PWM只跟随手机下发的转速百分比；手动模式下如果温度超过安全上限（比如40℃），无论手动转速多少，系统都强制提升到80%以上甚至全速，直到温度回落到安全值。这个安全冗余逻辑非常加分，答辩时一句“即使在手动模式，过热保护依然生效”就能体现你考虑问题的周全性。

切换逻辑里的状态同步也得注意：手机端显示的模式一定要和STM32实际模式一致，否则用户看到APP显示“自动”但风扇不受控，就会觉得系统坏了。每次状态变化STM32都会主动上行一帧状态消息，APP收到后刷新界面，不靠APP做本地状态管理，彻底避免两端状态不一致。

5. 调试实录：串口、WiFi与常见问题的排查方法论

5.1 串口调试三板斧

硬件调试第一件事不是跑通代码，而是通过串口确认芯片“活着”。STM32上电后先用串口1连接USB转TTL，在初始化代码的最前面加一句打印，比如“System Boot OK”，能看到这句基本排除供电、时钟、下载三大故障。

串口调试要养成“每个关键动作都留打印”的习惯。比如DHT22读取成功打印温度，WiFi收到指令打印原始数据，模式切换打印当前模式。一开始你觉得打印太多影响执行效率，但到了排查问题的时候，你会感谢每一条日志。调试打印最好走串口1，WiFi走串口2，互不干扰。USB转TTL模块的TXD接板子的RXD，RXD接TXD，地线必接，这个交叉连接我每次接线都要在脑子里过一遍，接反了什么都收不到。

5.2 WiFi模块调试中那些让人抓狂的问题

WiFi模块调试是整个项目里最容易让人心态崩溃的环节，我把高频问题提前列出来。

第一个坑：ESP8266供电不足导致反复重启。现象是模块LED一闪一闪，AT指令时通时断。原因几乎都是3.3V供电能力不够。解决办法前面提过，独立LDO、单独供电，别跟其他外设挤一路。

第二个坑：AT指令串口乱码。ESP8266默认波特率通常是115200，但出厂可能被改成9600或者其他值，STM32串口2配的波特率必须和模块一致。刚拿到模块先用USB转TTL接电脑，打开串口助手发“AT\r\n”，能收到“OK”说明波特率正确，乱码就是波特率不匹配。

第三个坑：TCP连接不稳定，经常掉线。这个现象九成是路由器AP隔离或者无线信号弱导致的。在路由器后台关闭AP隔离（也叫“客户端隔离”，开启时设备之间禁止互相通信），或者把模块挪近路由器试试。另一种可能是一个TCP Server只允许一个客户端连接，旧的连接没断开时新的连接会失败，所以APP重连前必须先释放旧socket。

第四个坑：数据发出去收不到完整帧。这极大概率不是WiFi丢包，而是STM32串口接收中断被其他中断打断，导致一个帧被拆成好几段收进来。解决办法是用环形缓冲区攒数据，解析时不要一次收完整帧，而是持续往里丢字节，每丢一个字节就尝试解析一次，能解出来就说明一帧齐了。

5.3 常见问题速查表

把实操中最常踩的坑整理成一张速查表，方便你调试现场对照：

5.4 答辩现场演示的避坑建议

这个项目答辩时最容易出现的翻车现场就是“演示时设备连不上网络”。我的建议是：自带一个只开2.4G频段的小路由器作为演示专用网络，不要用实验室或宿舍的公用WiFi，因为你不知道其他人会不会占用信道、路由器有没有做设备隔离。在答辩正式开始前就把ESP8266连上这个专用网络，记住模块的IP，提前用APP连接一次并确认通信正常，再把手机切回飞行模式只保留WiFi，确保演示过程不会有消息通知打断你的操作。

另一个容易被追问的点：控制时延。老师可能会问“WiFi控制的延迟有多大？”如实回答即可：局域网内TCP通信单次指令往返大概20~50ms，加上MCU处理，人感觉不到延迟。如果你愿意展示细节，可以在温度界面旁边加一个“通信耗时”显示字段，发一条带时间戳的指令回来计算差值，这是非常硬核的实测数据。

6. 论文写作与项目扩展的经验补充

6.1 论文结构怎么搭

毕设论文不是代码说明书，而是“问题-方案-实现-验证”的完整叙事。建议章节安排：

• 绪论：讲温度控制/远程监控的背景，这部分的参考文献去知网搜“无线温控系统”、“智能风扇”看看别人做了什么，再引出你的改进点，比如“针对传统温控风扇只能本地控制的问题，设计了基于STM32和WiFi的远程温控系统”。
• 系统总体设计：画系统框图、数据链路图、功能模块划分，注意这里不要贴大段代码，而是讲架构。
• 硬件设计：各个模块的原理图、选型依据、电源规划，原理图可以用立创EDA画，切记要规范，引脚标号和网络标号不能省。
• 软件设计：下位机状态机、通信协议帧格式、控制算法公式推导、上位机界面功能说明。
• 系统测试：列出测试用例表格，覆盖自动模式测试、手动模式测试、通信延迟测试、异常断电恢复测试，每个用例给出测试环境、操作步骤、预期结果、实际结果，四行搞定一个用例。
• 总结与展望：客观写系统的不足，比如单点温度采集不够全面、外网控制依赖公网服务器等，这些是很好的“展望”素材。

6.2 可扩展的方向与个人心得

做完成品之后，这个系统可以扩展的方向其实很多。双传感器多点测温、加入加热棒做恒温控制（就是孵化器的思路）、用PID替代分段调速、接入物联网云平台做数据上云和曲线展示，哪怕论文里不实现，在展望部分写上这些，老师也会觉得你对方向有认识。

最后分享一条个人心得：做这种软硬结合的项目，最大的陷阱不是某个模块不会用，而是总想“把所有功能都做完美再连起来”。正确做法是先把单个模块单独测通，确定每个环节“单点可用”，再逐步联调。先在面包板上测DHT22，再测OLED，再单独用USB转TTL调ESP8266，最后才把它们插到主板上。每加一个模块就重复测一轮，问题被隔离到最小范围，调试成本成倍下降。我的项目从开始焊板到最终跑通完整链路，真正有效开发时间大概两周，其中一半时间都花在WiFi模块的供电和连接稳定上——这些细节提前重视起来，你的进度会顺畅很多。