做硬件原型时，选开发板经常会被两个方向拉扯。一个方向是尽量小，最好一开始就像最终产品；另一个方向是尽量好调，屏幕、接口、供电、示例代码都要方便。真开始动手以后，我更倾向于后者。早期原型不是为了证明外壳有多小，而是为了尽快确认传感器能不能读、数据显示是否稳定、网络是否能连、页面能不能看到真实数据。
这也是我先用 ESP32-S3-LCD-1.47 的原因。它不是最终设备的形态，但它适合作为第一块把事情跑通的板子。对环境感知这种项目来说，第一块板子的价值不是“长得像成品”，而是能帮我少猜一点、多看一点。

我选板子时先看调试效率

如果只看最终外观，ESP32-S3-LCD-1.47 肯定不算小。它带一块屏幕，板子上也有不少开发接口，放到随身设备里显然不现实。但原型开发早期，我更关心的是另一件事：出问题时能不能快速知道问题在哪。环境传感器项目里可能出问题的地方很多。传感器没有响应，可能是接线错了；读数跳动，可能是预热不够，也可能是环境真的变了；网页打不开，可能是 WiFi 没连上，也可能是 HTTP 服务没起来；页面里没有数据，可能是接口没返回，也可能是前端没有正确解析。如果开发板没有屏幕，很多时候只能接串口一点点看日志。串口当然重要，但它不适合给每个状态都做直观反馈。有屏幕后，至少能把设备当前 IP、联网状态、传感器状态和几个关键读数直接显示出来。这样一来，很多低级问题不用打开电脑日志就能先判断方向。 这块板子的价值就在这里：它把硬件状态变得可见。早期调试时，可见性比尺寸更重要。

屏幕不是装饰，它能少走很多弯路

带屏幕的板子容易被误解成“为了好看”。实际做下来，屏幕最有用的地方不是展示漂亮界面，而是把几个关键状态固定显示出来。我最希望屏幕显示的是这些信息：- 当前是否进入主程序；- WiFi 是否已连接；- 当前 IP 地址；- BME690 是否读到数据；- 温度、湿度、气体阻值是否在变化；- 数据是否正在上传；- 设备是不是处于配网模式。这些字段看起来很基础，但调试时很救命。比如网页打不开时，先看屏幕上有没有 IP。如果屏幕上都没有 IP，就不要先怀疑网页代码；如果屏幕上有 IP，但网页打不开，再去查 HTTP 服务和路由器网络。这里有个常见坑：很多人一看到浏览器打不开页面，就开始改前端、改接口、改跨域，最后才发现设备根本没连上 WiFi。屏幕把这种问题提前暴露出来，能少走不少弯路。

WiFi 能力决定了它不只是串口小板

如果这个原型只在串口里输出数据，它就更像一个传感器实验。串口能证明驱动工作，但很难证明后续页面、接口和数据展示这一层是否可用。ESP32-S3 自带 WiFi，这一点让原型可以从“能读数”往“能被网页访问”走一步。我希望设备上电后至少能做三件事。第一，没配置过 WiFi 时，打开一个临时热点，让手机或电脑连进去配网。第二，连上路由器后，在局域网里打开一个后台页面，能看到传感器读数和设备状态。第三，把最新数据上传到一个接口，网页 Demo 不一定非要和开发板在同一个局域网，也能看到硬件最新状态。 这些功能不一定一口气做完，但开发板必须支持继续往这个方向加。ESP32-S3 的 WiFi 能力刚好够用，不需要额外加通信模块，也不会让第一版硬件变得太复杂。

不要低估板厂示例的价值

这块板子最省时间的地方不是芯片本身，而是有现成板级示例。带屏幕的开发板并不是插上就能显示，LCD 初始化、背光、SPI 时序、LVGL 刷新、RGB 灯这些细节都要有人处理。如果从零开始写屏幕驱动，当然能学到很多东西，但对这个项目来说不划算。当前重点是环境传感器数据和网页展示，不是重新造一套屏幕驱动。更现实的路径是先跑通板厂原始 Demo，确认屏幕、背光和基础外设都正常，再把不需要的功能删掉，把自己的 BME690 采集和 WiFi 后台加进去。我通常会按这个顺序检查： text先跑空 ESP-IDF 工程，看工具链是否正常；再跑板厂原始 Demo，看屏幕和板级驱动是否正常；然后加入 BME690，看 I2C 和传感器是否正常；最后再加 WiFi、网页后台和上传逻辑。这个顺序看起来慢，其实最省时间。因为每一步只增加一个变量，哪里坏了比较容易查。

I2C 接口够用，但接线要留余地

BME690 这类传感器用 I2C 接起来并不复杂。当前接法里，SCK 接 GPIO9 作为 SCL，SDI 接 GPIO8 作为 SDA，SDO 接 GND 固定地址，CS 接 3V3 进入 I2C 模式。真正容易踩坑的地方不在表格，而在接线细节。比如 3V3 和 GND 常常不够用，需要面包板或一分多杜邦线分出来。再比如 SDO 如果没接好，I2C 地址可能和代码里配置的不一致。还有一个容易忽略的问题：杜邦线太松时，传感器并不是完全没数据，而是偶尔失败，这种故障比完全不工作更烦。 所以我不建议一开始就把线塞进封闭外壳里。先在桌面上把 I2C 扫描、芯片 ID、连续读数都确认清楚，再考虑固定结构。否则后面外壳装好了，回头查一根线松没松，会非常痛苦。

为什么不直接用更小的板子

当然可以用更小的 ESP32-C3、ESP32-S3 Mini，甚至后续自己画板。但第一版不一定要这么做。更小的板子会把问题集中到供电、接口、显示、调试和外设扩展上。尺寸小了，排查成本往往上升。早期原型最怕的是同时追求太多目标：既要小，又要能联网，又要能显示，又要能接传感器，还要能长时间稳定运行。这样做很容易让问题互相干扰。比如数据异常时，不知道是传感器问题、供电问题、外壳进气问题，还是代码算法问题。我的取舍是：第一版先用大一点、好调一点的板子，把传感器到网页这一段跑顺。等数据路径稳定以后，再换更小的板子做第二版。这样迁移时目标更明确，只需要回答“怎样在更小硬件上复现已有能力”，而不是从零摸索所有问题。

这块板子也不是没有缺点

选 ESP32-S3-LCD-1.47 并不代表它适合最终设备。它的缺点也很明显。首先，尺寸和外观不适合直接做随身设备。开发板上的接口、排针和屏幕布局都是为了调试，不是为了佩戴。其次，功耗还需要单独评估。带屏幕的板子在调试时方便，但如果后面要做随身形态，屏幕常亮、WiFi 上传频率、传感器采样频率都会影响续航。第三，板厂示例虽然省时间，但代码结构不一定适合长期维护。拿来用之前要删掉不需要的功能，把传感器、网络、界面逻辑拆开，否则后面会越来越难改。第四，开发板接口虽然方便，但也容易让人忽视真实产品里的结构问题。比如传感器进气位置、外壳开孔、充电接口、震动提醒，这些在桌面板子上都还没有真正解决。所以它适合做第一块验证板，不适合直接假装成最终产品。

我会怎么判断这块板子选得值不值

判断一块开发板值不值得用，不是看参数表有多漂亮，而是看它有没有帮你更快排查问题。对这次原型来说，我会看这些结果：- 屏幕能不能稳定显示设备状态；- 串口能不能持续输出 BME690 读数；- WiFi 配网能不能跑通；- 局域网后台能不能访问；- 网页能不能看到真实硬件数据；- 出问题时能不能快速分辨是传感器、网络、屏幕还是前端问题。 如果这些都能做到，这块板子就完成了早期验证。它不需要在第一天就证明自己适合量产，也不需要证明自己能塞进小外壳。早期开发板的作用就是把问题拆开，让每一步都能被看见。

照着选板时，我会先列一张排查表

如果重新选一块板子，我不会只看芯片型号，也不会只看店铺详情页里的参数。我会先列一张排查表，看它能不能支持自己的调试方式。 text能不能稳定串口输出；有没有足够方便的供电方式；有没有现成屏幕或至少有状态灯；有没有 WiFi 或其他通信方式；传感器接口是不是好接；有没有官方或板厂示例；坏了以后能不能快速判断是哪一层问题。这张表比单纯比较主频和内存更实用。主频高一点，不一定能帮你少踩坑；但屏幕能显示 IP、示例能跑通 LCD、I2C 引脚好接，这些会直接影响开发速度。这里还有一个经验：第一块板子可以“笨重一点”，但不要“难查一点”。早期原型最怕的是设备很小、接线很紧、状态不可见。一旦读数不对，你需要同时怀疑供电、传感器、代码、网络和外壳，排查会非常痛苦。我宁愿第一块板子看起来不像最终产品，也不愿它让我每一步都靠猜。等传感器、屏幕、WiFi、网页这些基础能力都跑顺以后，再把它迁移到更小的板子上，反而更容易知道自己在删什么、保留什么。所以选板不是一次性决定未来所有形态，而是给第一轮开发选一个好用的脚手架。脚手架可以不漂亮，但必须稳、清楚、方便排查。这也是我后面继续沿用这块板子的原因：它不是最小答案，却能把问题暴露得足够早。

最后我会把开发板分成三类看

选开发板时，最容易犯的错误是把“第一块能跑的板子”和“最终产品里的板子”混在一起看。两者当然有关联，但判断标准并不一样。第一块板子要帮你把未知问题尽快暴露出来；最终产品里的板子才需要认真压尺寸、压功耗、压成本。我现在会把板子大致分成三类：| 类型 | 适合解决的问题 | 不适合承担的事 | 当前判断 || — | — | — | — || 快速验证板 | 传感器接入、屏幕状态、WiFi、网页后台、日志排查 | 最终外壳尺寸、长期续航、成本控制 | ESP32-S3-LCD-1.47 更接近这一类 || 工程过渡板 | 把功能从开发台架迁移到较小尺寸，开始整理接口和供电 | 直接量产，或者把所有结构一次定死 | 后面可以考虑 || 最终形态板 | 尺寸、功耗、结构、装配方式更接近真实使用 | 反复试错和频繁飞线调试 | 不适合一开始就用 |这张表并不是为了把某块板子分出高低，而是为了避免在错误阶段追求错误目标。早期如果过分追求最终形态，很容易让调试成本变高。板子小了，状态少了，接线紧了，问题反而更难查。

放回这个环境感知原型里，它承担的是第一段路

对这个环境感知原型来说，ESP32-S3-LCD-1.47 不是为了证明“最终设备就长这样”。它承担的是第一段路：先把 BME690 读起来，把屏幕状态显示出来，把 WiFi 配网和网页后台跑通，再把数据流接到后面的异常判断里。所以我对这块板子的要求并不是“能不能直接做成随身设备”，而是下面这些更具体的问题：- BME690 接上以后，I2C 地址能不能稳定识别；- 温湿度、气压、气体阻值能不能连续输出；- 屏幕能不能把设备状态、IP、传感器状态讲清楚；- WiFi 连接失败时，有没有办法快速判断原因；- 局域网后台能不能看到真实数据；- 后续把屏幕、传感器、网络拆到更小板子上时，哪些代码还能复用。只要这些问题能回答清楚，这块板子在第一阶段就是合格的。它不需要一开始就解决外壳、不需要一开始就解决续航，也不需要一开始就把随身形态做完整。那些问题要做，但不应该抢在传感器链路和数据链路前面。

真正要警惕的是过早小型化

过早小型化看起来很诱人，因为它会让原型更像产品。但硬件项目里，“像产品”不等于“问题已经解决”。如果传感器还没稳定读数，网页还没看到真实数据，异常判断还没有基本逻辑，这时候去压外壳和板子尺寸，往往只是在把调试难度提前放大。我更愿意先接受一块看起来不够精致的开发板，把它当成透明的调试台架。等读数、屏幕、网络、接口这些关键链路都稳定以后，再去考虑更小的板子、独立供电、外壳结构和安装方式。这样迁移时，至少知道自己迁移的是一套已经跑顺的链路，而不是一堆还没定位清楚的问题。这也是第二篇真正想收住的地方：选型不是为了选一块“永远正确”的板子，而是为了选一块能把当前阶段推进下去的板子。下一步就不能再停留在选型了，要开始接 BME690，看这块板子到底能不能稳定读到第一批传感器数据。

写到这里，选板子的思路其实很简单

我现在更愿意把开发板分成两类：一类适合做最终形态，一类适合把原型跑通。ESP32-S3-LCD-1.47 属于后者。它不够小，但足够好调；它不够像产品，但能让我更快看到状态；它不是最终答案，但能把后续问题暴露出来。 如果你也在做类似的环境传感器项目，第一块板子不一定要追求最小。先问自己几个问题：能不能看见状态？能不能接传感器？能不能联网？能不能快速烧录？出问题时有没有足够的日志和页面可查？这些问题回答清楚以后，再谈小型化会更稳。否则很容易把时间花在外观和结构上，最后发现最基础的传感器数据还没有真正跑顺。

阅读顺序

这一组文章建议按标题前面的序号阅读：01 → 02 → 03 → 04 → 05 → 06 → 07 → 08 → 09 → 10。当前这篇是 02｜开发板选型复盘：为什么我先用 ESP32-S3-LCD-1.47 做原型。

下一篇

下一篇： 03｜BME690 接入实战：从接线、I2C 地址到第一条传感器日志