企业官网建设流程全解析

最近帮几个朋友捣鼓库房、花棚和冷链箱的温湿度监测项目，发现一个很反直觉的事：DHT11 这种传感器选型反而简单，真正折磨人的是"数据怎么传回来"。同样一个温湿度传感器，放到机房里、放到农业大棚里、放到运输途中、放到山区监测点，联网方案会完全不同——有线、WiFi、蜂窝、LoRa 这四条路我都实际部署过，各有各的优势，也各有各的坑。

这篇文章我就把这四种方案从原理、硬件选型、功耗、成本、实测体会到选型决策，完完整整地对比一遍。不管你是在做单片机小项目、温室大棚监控，还是想给仓库做温湿度记录，只要还在纠结"用哪种方式联网"，这篇应该能帮你省下不少试错时间。

1. 先别急着买模块：把需求场景拆透

很多人犯的第一个错误，是上来就问"哪个方案最好"。实际上没有最好的方案，只有最合适的方案。在做任何技术选型之前，先把三个问题想清楚，至少能帮你排除掉一半的错误选项。

1.1 你连的是"一台设备"还是"一片区域"

这是最基础的问题。如果一个项目里只有三五台设备，而且都在同一个房间，那有线或者 WiFi 都很合适；但如果你要监控的是分布在一个园区里的几十个点位，每个点位之间隔了几百米，那 WiFi 就需要多个 AP 覆盖，布线和交换机成本也会上来，这时候 LoRa 或蜂窝反而更有竞争力。

我有个朋友做粮仓监测，一开始他想当然地选了 WiFi，结果每个仓房要单独配一个路由器，还要保证穿墙信号。后来换成了 RS485 有线总线，一条双绞线串起十几个仓房，省了一大堆网络设备。这就是典型的"集中区域"和"分散区域"的区别。

1.2 供电条件是第一道分水岭

这个问题经常被新手忽略，但它几乎直接决定了联网方案的选择。

• 如果你的传感器旁边就有 220V 插座，那有线、WiFi、蜂窝随便选，功耗不是核心矛盾。
• 如果只能用电池供电，而且要求设备跑一年以上，那 WiFi 基本可以直接出局，LoRa 或者 NB-IoT 才是正路。

我做过一个冷库温度记录仪项目，用两节 18650 电池供电，每个小时上报一次温度。最初用 ESP8266 模块，结果电池一个月就耗光了。后来换成了 LoRa 模块，同样的电池跑了大半年还有电。这不是什么高深技术，纯粹是功耗层面的物理差异。

1.3 你要的到底是"实时"还是"够用"

还有一个关键维度是数据时效性。冷链运输的温度报警，要求延误不能超过几分钟，否则食品就可能变质；但粮仓里的温湿度，半小时上报一次完全够用。这个需求差异会直接影响方案选择：

另外，温湿度数据本身就是几十字节的小包，完全用不到高带宽。很多人担心 LoRa 速率太低，其实对温湿度传感器来说，LoRa 的速率绰绰有余。

2. 有线方案：最老、最稳、但部署成本容易被低估

很多人一想到温湿度传感器就默认是无线方案，反而把有线这个最可靠的方案给忽略了。实际上，在工厂、机房、仓库这些固定场所，有线方案依然是最推荐的选择。

2.1 RS485 总线 + Modbus：一条双绞线串起几十个节点

RS485 是工业现场最经典的通信总线，它使用差分信号传输，A、B 两根线，抗干扰能力远超普通串口。为什么要用 RS485 而不是直接用 TTL 串口？因为 TTL 电平的传输距离通常只有几米，而 RS485 在 9600 波特率下能轻松跑到 1200 米，而且支持多点拓扑，一条总线上可以挂几十个设备。

具体的硬件组合我推荐这样：

• 主控：STM32F103 或者任何带 UART 的单片机
• 收发器：MAX485 或 SP3485 芯片
• 传感器端：直接购买带 RS485 输出的温湿度探头，内部已经集成了传感器和收发电路
• 通信协议：Modbus RTU，主站轮询各从站地址

接线时有几个常年踩坑的点，我单独列出来：

A/B 线千万不要接反，接反了通信大概率不通；总线两端要加 120Ω 终端电阻，特别是距离长、节点多的时候；屏蔽层单端接地，不要两端都接地，否则容易形成地环路。波特率我建议选 9600 或 19200，稳定可靠，没必要追求高速。

传感器端的选择，如果预算实在紧张可以用 DHT11 自己改造，但我实际用下来，DHT11 的精度只有 ±2℃ 和 ±5%RH，响应也很慢，做工业记录不太合适。我更多使用 SHT30 或 BME280 这类数字传感器，再通过一个 RS485 转 TTL 模块接到总线上，整体成本也就几十块钱。

2.2 以太网方案：机房场景的稳妥选择

如果你的现场本来就铺设了网线，那直接用 RJ45 以太网是最省事的。一个温湿度探头带网口，插上交换机，内网随便访问，甚至还能分配一个固定 IP 做 Web 页面显示数据。

以太网方案的优点非常明显：

• 带宽极大，哪怕同时传几十个传感器的数据都毫无压力
• 稳定性好，只要网线、交换机不坏，链路就不会断
• 可以实现 PoE 供电，一根网线同时解决数据和电源

但缺点也同样明显：如果现场没有现成的网线，重新布线的成本会非常高。我之前给一个旧厂房做监测，现场根本没有网络布线，从交换机拉网线到各个点位，穿管、开槽、恢复墙面，成本比传感器本身贵了好几倍。所以我的建议是：己有网络基础设施的选以太网，什么都没有的选 RS485 或者无线。

2.3 有线方案实测体会与避坑

在有线方案上，我踩过的坑主要集中在这几点：

干扰问题。工厂环境里变频器、电机、大功率设备启动时，会对 RS485 通信产生明显干扰。解决方法是使用屏蔽双绞线，并且屏蔽层单端接地。我遇到过一次严重丢包的情况，排查了好几天，最后发现是双绞线走线时和动力电缆平行了太长距离，重新分开走线后问题消失。

距离与节点数。虽然理论上 1200 米没问题，但实际中如果节点超过 32 个，接收器负载会增大，建议加中继器或者分总线。另外，总线分支不要太长，最好采用"手拉手"菊花链结构，而不是星形结构。

防雷与浪涌。如果室外走线比较长，到雷雨季节很容易感应浪涌电压，损坏收发器。建议选用带 TVS 管的 RS485 收发器，或者在总线上加防雷器，成本不高但能省很多维修麻烦。

3. WiFi 方案：上手最快，但功耗和稳定性是两道坎

WiFi 应该是做 DIY 项目时最常用的方案，没有之一。ESP8266 模块几块钱一个，写代码的生态也非常完善。但作为温湿度传感器的联网方案，WiFi 有两个绕不开的问题。

3.1 主流硬件组合与传感器选择

WiFi 方案的硬件组合非常成熟，主流是：

• 主控 + WiFi：ESP8266 或 ESP32
• 传感器：DHT11 / DHT22 / SHT30 / BME280
• 传输协议：MQTT / HTTP

ESP8266 的优势是便宜、生态好，Arduino、MicroPython、ESPHome 都支持，写起来非常顺手。ESP32 比 ESP8266 贵一点，但性能更强，自带蓝牙，ADC 也更准确，适合后续要扩展的项目。

传感器方面，网上最多的教程是用 DHT11，因为它便宜，接线也只要一根数据线。但我要说实话：DHT11 的测量精度和长期稳定性都不太行，尤其是湿度，时间长了容易漂移。如果你做的是需要记录数据、做分析的项目，我建议至少用 DHT22（AM2302）或者 SHT30。BME280 更好，但注意它测的是气压而不只是温湿度，代码里要忽略气压字段。

3.2 功耗问题：为什么 WiFi 不适合电池供电

WiFi 模块的工作电流一般在 70-100mA 左右，连接路由器时还会有瞬时尖峰。即便你让它大部分时间休眠，只要它一醒来去连接 WiFi，那几秒钟的高电流就会消耗大量电量。

我们来算一笔账：假设你用 2000mAh 锂电池供电，ESP8266 每 10 分钟唤醒一次，每次花 3 秒完成连接和上报，平均电流大约是 0.4mA 左右。听起来不大对不对？但实际上 WiFi 连接时间往往不止 3 秒，如果路由器信号不好、DHCP 获取 IP 慢、或者 MQTT 服务器响应慢，一次唤醒可能要 5-10 秒。再加上锂电自放电，2000mAh 实际能撑半年就不错了。

如果一定要用 WiFi 做电池供电，可以采取这些策略：

• 每次上报后立即进入 deep sleep
• 关闭 WiFi 后，通过定时器唤醒，而不是保持连接
• 尽量靠近路由器，缩短连接时间
• 用 ESP32 的 ULP 协处理器实现更细粒度的功耗控制

但我个人强烈建议：WiFi 方案只用插座供电，别跟电池较劲。同一个项目想用电池供电，直接去看 LoRa 或者 NB-IoT，省得后期因为耗电问题推翻重来。

3.3 稳定性：掉线、重连、看门狗，一个都不能少

WiFi 方案最大的痛点是稳定性。我做过一个办公室温湿度监测项目，10 个 ESP8266 节点，刚开始跑得很开心，但后来发现几个节点会时不时掉线，有的甚至一周掉好几次。

排查一圈后，问题集中在几个地方：

路由器连接数限制。很多家用路由器能同时连接的设备数量有限，设备一多就会踢掉老设备。解决办法是换企业级 AP，或者减少节点数量。

DHCP 租期问题。节点长期离线再上线，可能获取不到 IP。我在代码里直接给每个节点配置静态 IP，避免依赖 DHCP。

信号弱导致的重连失败。ESP8266 在信号弱的情况下会反复尝试连接，每次尝试耗电又耗时。我在固件里加了信号强度判断，低于某个阈值就延长重试间隔，避免陷入死循环。

还有一个必须做的保障：硬件看门狗或软件看门狗。WiFi 模块跑久了难免出现死机。用软件定时器喂狗，一旦程序卡死就自动重启，能避免"悄悄死掉"的情况。

传输层我建议用 MQTT，配合一个本地或者云端的 Broker。为什么不用 HTTP？因为 MQTT 是长连接，服务器能随时知道节点是否在线，节点上报数据也快。HTTP 每次都要重建连接，开销更好功耗更高。温湿度传感器这种小数据量应用，MQTT 是更合适的选择。

3.4 WiFi 安全与日常使用注意

WiFi 方案连接的是你家或公司的无线网络，安全问题也不能忽略。几个基本建议：不要使用弱密码、尽量用 WPA2/WPA3 加密、不要随意开放网络。至于隐藏 SSID 和 MAC 白名单，能提高一些安全性，但会给初次配置带来麻烦，对大多数项目来说没必要。设置一个好记又安全的密码，足够解决问题。

4. 蜂窝方案：无死角覆盖，但钱和电都要花

当你需要在没有有线、也没有 WiFi 覆盖的地方采集温湿度，比如：

• 野外环境监测点
• 冷链运输车
• 偏远库房
• 临时工地

蜂窝方案就是最简单粗暴的选择——只要能打得通电话，数据就能传回来。但蜂窝方案的两个"代价"：流量费和功耗，必须认真对待。

4.1 4G Cat.1、NB-IoT 与 Cat-M，到底选哪个

很多人以为"蜂窝"就是 4G 手机模块，其实在物联网领域，蜂窝方案也是分派的。我实际用过下面几种：

4G Cat.1。全称是 LTE Cat.1，速率理论值能到 5-10Mbps 下行，2-5Mbps 上行，时延较低。它的优势是兼容性好，全国几乎都有 4G 覆盖，而且因为速率不算太高，功耗比普通手机 4G 模块低一些。常见模块有 EC200S、Air724UG 等。适合需要实时数据、可能偶尔传张图表的应用。

NB-IoT。窄带物联网，专门为低功耗、低频次、小数据量的设备设计。速率只有几十 kbps，但穿透能力很强，地下车库、地下室也能收到信号。它的功耗非常低，支持 PSM（省电模式）和 eDRX，可以做到几年不换电池。常见模块有 BC26、BC35-G。

Cat-M。介于 Cat.1 和 NB-IoT 之间，但国内实际部署不多，一般主要是海外运营商在推。做国内项目基本不用考虑。

我的选型经验是：

温湿度传感器这种场景，大部分情况下 NB-IoT 更合适，前提是你的项目地区 NB-IoT 网络覆盖到位。如果覆盖不行，就老老实实上 Cat.1。

4.2 数据量、资费与信号覆盖

很多人担心蜂窝方案流量费很贵，我实际算了一下，温湿度上报的流量小到你完全不用担心：

假设每 10 分钟上报一次，一次数据包按 100 字节算（包含协议头部、时间戳、温湿度），一天 144 次，一个月大约 432KB，不到 1MB。哪怕加上 MQTT 保活的心跳包，一个月也就在 2MB 以内。运营商的物联网卡套餐，一年几块钱到几十块钱基本都能覆盖这个量级。

不过物联网卡本身需要注意几点：

• 开通和管理通常比普通手机卡繁琐一些，需要预留开通时间
• 要注意续费周期，欠费停机后重新激活比较麻烦
• 对设备量大的项目，建议做一张台账，记录每张卡的号码、到期时间、对应设备

信号覆盖方面，我一直坚持"以实测为准"。NB-IoT 理论覆盖深度好，但这几年建网情况各地区差异很大。我之前在沿海某市做过测试，市区 NB-IoT 信号满格，但偏一点的老厂房地下室里完全没信号。所以不要只看标称，最好先拿开发板到实际点位跑一圈再说。

4.3 蜂窝方案的功耗策略

蜂窝模块的功耗大头在射频发射。Cat.1 模块在发射信号时，瞬间电流可能冲到 300-500mA，虽然持续时间短，但对电池的压力很大。NB-IoT 在弱网环境下会反复重传，功耗也会飙升。

几个降低功耗的常用手段：

• 尽量保持模块已经附着网络，不要频繁开关机。频繁重新附着网络比保持在线更耗电
• 用 PSM 或 eDRX 模式，让模块在不发送数据时进入省电状态
• 上报频率能低就低，比如一小时一次，而不是一分钟一次
• 电源设计上，用大容量电池 + DCDC 稳压，避免射频瞬间拉低电压导致重启

蜂窝方案还有一个容易被忽略的问题：如果要放到偏远地区，一定要测试不同运营商的实际信号。我之前在某山区遇到过移动信号满格、电信完全没有的情况，选错运营商会让设备直接变砖。同型号模块，三家运营商的物联网卡都测一遍，再决定用哪家。

5. LoRa 方案：低功耗远距离的王牌，但组网是真正的门槛

LoRa 是最近几年物联网圈最常被提起的技术之一。但很多人的理解是"LoRa=传得远"，这个理解只对了一半。LoRa 真正的优势是：极远的传输距离 + 极低的功耗 + 免费的频段。但它也有明显的边界条件。

5.1 LoRa 到底是怎么实现"传得远"的

LoRa 本质上是一种调制技术，全称是 Long Range，它使用了一种叫做"线性调频扩频"的方式，把信号在很宽的频带上展开，接收端通过相关运算把它解调出来。通俗讲，它不是靠"喊得更大声"来传得远，而是靠"在大噪音里分辨出一个微弱但特征明显的信号"来传得远。

这就解释了为什么 LoRa 能在发送功率只有 17dBm 左右的时候，实现几公里的传输距离。LoRa 的接收灵敏度可以做到 -137dBm 甚至更高，这个数值比 WiFi 要低得多，意味着它能听到更微弱的声音。

实际中我们会调节几个参数：

• 扩频因子（SF）：SF7 到 SF12，数值越大，灵敏度越高、传输越远，但速率越低
• 带宽（BW）：125kHz 到 500kHz，带宽越宽速率越高，但灵敏度会下降
• 编码率（CR）：冗余越高，抗干扰越强，有效速率越低

我常用的组合是 SF12、125kHz 带宽，这样能把距离拉到最远，代价是速率只有几百 bps。对温湿度传感器这种几十字节的数据包，这个速率完全够用。

5.2 实测距离：别被"几十公里"的宣传骗了

LoRa 的宣传资料里经常写"最远几十公里"，但那是在海面、沙漠等完全开阔且没有遮挡的环境下测出来的。我实际测试的城市和郊区结果如下：

这些数据仅供参考，因为天线高度对 LoRa 的影响非常巨大。把天线从 1 米升到 10 米，传输距离可能直接翻好几倍。如果你的网关在楼顶，节点在楼下，那效果会比两个天线都放在地面上好得多。

几个实际经验：

• 天线位置比发射功率更重要。天线架高、避开金属遮挡，比调大功率有效得多
• 天线馈线越短越好。馈线本身有损耗，长了等于白烧功率
• 别把 LoRa 模块贴在金属表面上，天线会被严重失配，造成驻波比过高，距离骤降

5.3 自组网还是用 LoRaWAN 网关

LoRa 的一个坑在于：搞定了点对点通信之后，你还需要考虑多节点怎么组网。这个环节有两种路线：

路线一：自组网（点对点 / 星型）

买一对 LoRa 模块，比如 SX1278、SX1262 为核心的模块，一个做发送端，一个做接收端，通过 UART 透传。如果只有一个或几个节点，主站轮询或者节点定时上报，这就够了。代码层面很简单，很多模块直接发 AT 指令就行。

但自组网的问题也很明显：没有链路层协议，节点多了之后，碰撞、重传、补报都要自己处理。我的经验是，如果节点数量在十几二十个以内，且上报频率不高，自组网完全可行；但如果你搞不清楚 ARP 和冲突处理，或者节点数量多，还是走正规协议更省心。

路线二：LoRaWAN

LoRaWAN 是一个完整的 MAC 层协议，定义了节点、网关、网络服务器之间的关系。节点只发送给网关，网关通过网络回传数据给服务器，服务器做认证和数据处理。

LoRaWAN 的好处是：

• 支持大量的节点，网络容量大
• 自带的加密、入网激活流程
• 支持 ADR（自适应数据速率），自动调节节点的速率和功率，达到省电和远距离的平衡

代价是你要部署网关。商业网关价格从几百到几千不等，比如 RAK 系列、八信道的 SX1302 网关。你也可以用树莓派 + LoRaWAN 网卡自己搭一个，但稳定性要自己维护。

我的建议是：如果只是玩一玩、传感器不超过十个，自组网透传就行；如果要做正经项目、节点多、要求稳定，直接上 LoRaWAN，别在自组网上浪费时间。

5.4 LoRa 的边界：速率、频段和响应时延

最后说一下 LoRa 的几个硬边界。

速率低。哪怕最高速率，LoRa 也就几十 kbps，传不了图片、音频，更不可能实时传输视频。如果你需要远程抓拍几张现场照片，LoRa 做不到，那是蜂窝方案的活。

频段管理。LoRa 用的是免授权频段，但各国对免授权频段都有相应的管理要求，包括发射功率上限和占空比限制。国内常用的是 470MHz 到 510MHz 这一段的免授权频段，但实际部署前，建议根据当地允许的频段和功率来配置，别盲目调大功率，否则不仅违规，还可能干扰到别人的设备。

实时性。LoRa 的一次数据包传输需要数百毫秒到数秒，取决于扩频因子和包长。如果是冷链报警这类需要秒级响应的，LoRa 也能做到，但必须把周期设计好，不要真的把占空比跑满。它适合"定期上报"和"当日报警"这两种模式，不适合持续高速交互。

6. 四种方案横向对比与选型建议

前面四章分别讲透了四种方案的原理和实测体会，这一章我把它们放到一张表里做最终横评。这张表是我在多个项目中反复验证后总结出来的，可以作为你选型时的第一参考。

6.1 核心参数对照

从表里可以看出一条很明显的脉络：网络基础设施越是现成的，部署越便宜；越是要自己搭建覆盖，成本越高。WiFi 最便宜是因为路由器到处都是，蜂窝最省心是因为基站运营商已经建好了，LoRa 最贵是因为网关得你自己买、自己架。

6.2 我的选型决策清单

到这里，我可以给出一份可直接套用的决策流程。拿到一个温湿度监测项目，按这个顺序问自己：

1. 现场有没有 220V 电源？

   • 有：有线或者 WiFi 都可以，继续看现场有没有网线/网络覆盖
   • 没有，只能电池：直接跳到 LoRa 或 NB-IoT，别碰 WiFi

2. 现场有没有现成的网络基础设施？

   • 有网线：以太网方案优先，稳定省心
   • 有 WiFi 覆盖：WiFi 方案，部署最快
   • 什么都没有：LoRa 或蜂窝二选一

3. 节点分布是集中还是分散？

   • 集中在几百米内：RS485 或 LoRa，成本可控
   • 跨地域分散：蜂窝，信号无处不在

4. 数据上报频率和实时性要求？

   • 秒级实时报警：有线、WiFi、蜂窝
   • 分钟级定期上报：LoRa、NB-IoT

5. 长期运维的耐心程度？

   • 希望设备上线后基本忘掉它：有线最省心，其次是蜂窝
   • 愿意偶尔维护网关：LoRa 也可以

6.3 无论走哪条链路，这几点都通用

最后分享几个跨方案通用的经验，不管你最终选了哪种联网方式，都用得上：

数据格式最好统一。我在多个项目里坚持用统一的 JSON 格式上报：设备 ID、时间戳、温度、湿度、电池电压、信号强度（RSSI）。这样即使以后从 WiFi 方案迁到 LoRa 方案，服务端的解析逻辑几乎不用改。

信号强度必须上报。温湿度是业务数据，信号强度才是健康数据。有了 RSSI 日志，排查故障时能直观看到哪些设备处于信号边缘。

服务端做离线判断。不要指望传感器端永远在线，服务端要根据心跳和上报时间判断设备是否失联，超时没上报就告警。这个逻辑不管走 WiFi 还是 LoRa 都成立。

就我个人这些年做温湿度监测项目的体会，最常犯的错就是把"我能跑通 Demo"等同于"我能稳定运行一年"。Demo 阶段跑通 WiFi 传输非常容易，但一旦放到现场，电源问题、信号问题、网络问题全都会冒出来。所以选型时宁可多花点时间做现场测试，也别等全部设备部署完再回头改方案——我在 LoRa 项目里吃过这个亏，前期省下的选型时间，后期全在维护上还了回来。