企业官网建设流程全解析

硬件项目如果只能靠串口看数据，调试时当然没问题，但它很难变成一个真正“可访问”的设备。每次都要插 USB、打开串口、找日志，对自己还可以，对别人就不太友好。环境传感器这种项目更需要网页后台，因为很多状态用表格和页面看，比盯串口舒服得多。
这次我给 ESP32-S3 做了一个简单的 WiFi 配网和网页后台。它不追求复杂后台系统，只解决几个实际问题：第一次上电怎么配网，连上路由器后怎么找到设备，怎么看 BME690 数据，怎么重启或清除 WiFi。

先把第一次联网这件事想清楚

开发板第一次上电时，还不知道家里的 WiFi 名称和密码。这个时候不能指望它直接连上网络。比较简单的做法是：设备先开一个临时热点，手机或电脑连上这个热点，再打开一个固定地址配置 WiFi。流程大概是这样：text设备没有保存 WiFi -> 开启临时热点手机或电脑连接热点 -> 打开 192.168.4.1网页里选择路由器 -> 输入密码设备保存配置 -> 重启或重新连接连上路由器 -> 屏幕显示局域网 IP这里最容易踩的坑是：设备明明开了热点，但用户不知道下一步打开哪个地址。所以屏幕上最好直接显示：textAP: SENSOR-XXXXIP: 192.168.4.1USER: adminPW: password_hidden这样就不用翻说明文档。

WiFi 信息要存起来，但别写死在代码里

调试时把 WiFi 名称和密码写死在代码里很方便，但不适合长期使用。换一个路由器、换一个地方、换一个网络，就要重新编译烧录。更合理的做法是把 WiFi 配置写入 NVS。伪代码可以这样理解：ctypedef struct { char ssid[33]; char password[65]; bool valid;} wifi_config_saved_t;bool load_wifi_config(wifi_config_saved_t *cfg){ // 从 NVS 读取 ssid、password、valid // 读取失败或 valid 为 false，就进入配网模式}void save_wifi_config(const char *ssid, const char *password){ // 写入 NVS，并标记 valid}这里要注意两点。第一，密码不要打印到普通日志里。第二，清除 WiFi 的功能要保留。否则输错密码以后，设备会一直尝试连接错误网络，用户很难恢复。

网页后台先做少，但字段要真

网页后台不需要一开始做得很花。早期我更在意字段是否真实、是否有用。后台首页至少要有：- 当前 WiFi 状态；- 设备 IP；- BME690 是否 ready；- 温度；- 湿度；- 气体阻值；- 数据更新时间；- 上传状态；- 重启按钮；- 清除 WiFi 按钮。这些字段看起来普通，但排查问题时很有用。比如传感器页面有数据，但上传状态失败，就去查上传接口；如果更新时间不变，就先查采集任务；如果 WiFi 已连接但页面打不开，就看 HTTP 服务有没有启动。

接口返回最好也是 JSON

网页页面可以渲染表格，但接口本身最好返回 JSON。这样前端页面、调试工具、后续 Demo 都能直接复用同一份数据。一个简单的/api/status可以这样返回：json{ "wifi": "connected", "ip": "192.168.31.158", "sensor": "ready", "temperature": 25.3, "humidity": 48.2, "gas_raw": 26.64, "warmup": false, "source": "live_hardware", "updated_at": 1782201600000}这里的updated_at很关键。没有时间戳时，页面显示了数据，也不知道是不是旧数据。很多“传感器没变化”的问题，最后发现其实是网页还在显示缓存或旧值。

基础认证可以有，但别把它当安全方案

局域网后台可以加一个简单的账号密码，避免同一网络里随便打开页面就能改设备配置。但这只是基础保护，不是完整安全方案。早期可以先用 HTTP Basic Auth 或简单登录，重点是防止误操作，比如重启设备、清除 WiFi。密码不要写在文章里，也不要放进公开仓库。示例代码里可以用占位值：c#define WEB_USER "admin"#define WEB_PASS "change_this_password"更稳妥的做法是把密码放在本地私有头文件或构建配置里，不提交到公开代码。即使只是个人项目，也要养成这个习惯。

网页打不开时，不要先改前端

网页打不开是最常见的问题之一。排查时不要先怀疑 HTML，也不要马上改 JavaScript。我一般按这个顺序来：text1. 屏幕上有没有显示 IP；2. 电脑是否和设备在同一个路由器下；3. 能不能 ping 到设备；4. 串口里 HTTP 服务是否启动；5. 浏览器访问的是不是正确地址；6. 页面能打开但数据为空时，再查接口。这个顺序能避免很多无效修改。比如设备没连上 WiFi 时，改前端没有意义；HTTP 服务没启动时，改页面也没有意义。

重启和清除 WiFi 是两个很实用的按钮

网页后台里我会放两个朴素但实用的操作：重启设备和清除 WiFi。重启设备用于快速恢复状态。比如上传任务卡住、网络切换后状态异常，可以不用拔线，直接页面重启。清除 WiFi 用于重新配网。输错密码、换路由器、换地方测试时都需要它。如果没有这个按钮，就只能通过串口命令或重新烧录处理，体验很差。当然，这两个按钮都不能随便开放。至少要放在登录之后，并且点击前给出确认提示。否则误点一下，设备就断网或重启了。

上传状态也要放在后台里

如果设备后面要把数据上传到云端或远程接口，后台里最好显示上传状态。只在串口里打印上传结果，排查时不够直观。我会显示这些字段：- 最近一次上传是否成功；- 最近一次上传时间；- HTTP 状态码；- 失败次数；- 当前数据来源。这些字段能帮助判断问题在本地采集、局域网后台，还是远程接口。没有这些信息时，页面没数据就只能盲猜。

接口字段最好从一开始就固定

网页后台写到后面，最怕字段名来回变。今天叫gas，明天叫gas_raw，后天又改成gasValue，前端和固件很快就会互相对不上。我更建议一开始就把字段命名固定下来，哪怕字段多一点也没关系。比如温度统一用temperature，湿度用humidity，气体原始值用gas_raw，数据来源用source，更新时间用updated_at。字段名稳定以后，前端页面、上传接口和本地后台都能复用。这个习惯看起来小，但能减少很多低级错误。尤其是硬件端和网页端分开调试时，字段名不一致会让你误以为数据没上传，实际只是前端读错了字段。

配网失败时要给用户退路

配网最怕设备一直卡在连接状态。比如密码输错了，设备不断重连，但用户不知道怎么回到配网页面。我的做法是保留一个清除 WiFi 的入口，并且在多次连接失败后重新开放热点。逻辑可以很简单：text连续连接失败达到阈值；停止当前连接尝试；重新打开配置热点；屏幕提示重新配网地址。这样就算密码输错，也能恢复。不要让用户只能拔电、重刷固件或接串口命令。对一个需要长期放在家里的设备来说，可恢复性比一次配网成功更重要。还有一种情况也要考虑：路由器换了，设备还保存着旧 WiFi。它可能会一直尝试连接旧网络，屏幕上如果没有明确提示，用户会以为设备坏了。所以屏幕和后台都应该能告诉用户当前是在连接、失败，还是已经回到配网模式。这类细节不复杂，但非常影响体验。硬件项目不是只要在开发桌上跑通一次就结束，换一个网络环境后能不能恢复，才更接近真实使用。所以后台里要保留“清除配置”和“重启设备”这种朴素功能。它们不酷，但关键时刻能让设备从错误状态里回来。我更愿意把这些功能称为“救命按钮”。平时用得少，出问题时比任何漂亮页面都重要。尤其是清除 WiFi。只要设备需要被带到不同网络环境里测试，这个功能就不是可选项，而是必须留的恢复入口。这个入口越早做，后面调试越轻松，也能避免很多重复烧录。

写到这里，网页后台的重点不是漂亮

网页后台的第一价值是把设备变得可访问、可排查。它不用一开始就像正式产品后台，但要把关键状态讲清楚：设备连没连上网，传感器有没有数据，数据是不是新的，上传有没有成功。如果你也在做 ESP32 传感器项目，不建议一直停留在串口阶段。串口适合底层调试，网页后台适合把状态暴露出来。只要后台字段真实、入口清楚、恢复操作可用，后续再做更漂亮的页面就会容易很多。

阅读顺序

这一组文章建议按标题前面的序号阅读：01 → 02 → 03 → 04 → 05 → 06 → 07 → 08 → 09 → 10。当前这篇是 06｜WiFi 配网与网页后台：让硬件从串口设备变成可访问设备。

下一篇

下一篇： 07｜从原始气体阻值到异常评分：环境基线算法的第一版设计