一台联网控制器、一只电池供电的 Thread 传感器、一台带唤醒词的语音终端和一块带摄像头的屏幕，不能因为都能用 ESP32 就共用一张芯片清单。先决定产品里哪颗芯片负责联网、哪颗负责交互，以及断网和待机时哪些功能必须继续工作；系列选择才会从“型号偏好”变成可验证的系统方案。
这里有一条最容易误判的边界：ESP32-H2 适合承担 802.15.4 节点职责，但它没有原生 Wi-Fi；ESP32-P4 可承担更重的屏幕、相机与处理职责，但也没有原生 Wi-Fi。把两者写成单芯片 Wi-Fi 产品，会在原理图和固件分工阶段留下缺口。下文依据 Espressif 官方芯片与 SDK 文档讨论产品架构选择，不是吞吐量、待机电流或语音识别准确率实测。
先把产品拆成职责，而不是把型号排成名次
采购表通常问“C3、S3、C6、H2、P4 哪个更强”。工程上更有用的提问是：主控要连接什么网络？谁维持本地控制？屏幕或音频的峰值负载落在哪里？未来协议是否可能变化？
| 产品中的职责 | 先看哪些系列 | 需要当场确认的缺口 |
|---|---|---|
| 2.4 GHz Wi-Fi 联网与常规控制 | ESP32-C3 等 Wi-Fi 主控 | GPIO、Flash、RAM、功耗和固件升级空间是否够本产品，而非只看无线标签 |
| Wi-Fi + Thread/Zigbee 组合或 Matter 路线 | ESP32-C6 等具备 802.15.4 的系列 | 产品到底是终端、桥接器还是边界路由器；协议栈与射频共存要另验 |
| Thread/Zigbee 低功耗节点 | ESP32-H2 | H2 不自带 Wi-Fi；若要求 Wi-Fi 上云，必须另设网关或第二颗联网芯片 |
| 本地语音与一般人机交互 | ESP32-S3 可作为候选 | 模型、音频前端、内存和延迟需按具体方案验证；“支持 WakeNet”不等于能离线自由对话 |
| 更重的图形、相机与多媒体处理 | ESP32-P4 | P4 不自带 Wi-Fi；无线方案与主从职责要在板级设计前确定 |
这张表不是采购结论。ESP32-C5 等双频候选、模块封装、温度等级与供货状态，可能改变最终 BOM；本文只把有官方文档支撑的代表性系列放在职责地图里。最终 SKU 必须回到目标芯片和模组的数据手册核对。
生成示意图，仅帮助辨认电池节点、显示处理板与独立无线模组的物理差异；不是 Espressif 官方开发板照片，也不能证明型号或性能。
比如同样叫“智能面板”，只显示温度和开关状态，与同时处理摄像头画面、动画和语音的面板，实际上是两道不同的选型题。前者应先验证简单方案是否足够，后者才需要评估处理侧与无线侧分工。把两者合并成一个“面板推荐芯片”，会让简单产品多付成本，也会让复杂产品低估资源需求。
单芯片方案先算三笔账
第一笔是常驻资源。网络协议栈、应用状态和 OTA 回滚空间会长期占用存储与内存；屏幕缓存或语音模型是额外负载，不能拿芯片峰值算力代替可用余量。第二笔是关键路径：网络拥塞时，本地按键、继电器或安全保护是否仍按预期工作。第三笔是变更成本：下一代产品若从 Wi-Fi 增加 Thread，换芯片、改板和迁移 SDK 的代价是多少。
若这三笔账都能在一颗带目标无线协议的 SoC 上闭合，单芯片通常减少 BOM 和跨芯片通信复杂度；如果音视频负载或无线能力无法同时满足，双芯片并不是“落后”，而是明确责任边界的代价。不要为了追求一颗芯片省料，把验证成本转嫁到量产后。
四个产品情境，答案并不相同
1. 普通联网控制器：先排除不需要的能力
假设设备有几个传感器、按键和执行器，2.4 GHz Wi-Fi 接入，断网时仍能本地控制，不做屏幕或本地语音。ESP32-C3 可作为基线候选：官方 ESP-IDF 文档确认其 Wi-Fi、Bluetooth LE 与单核 RISC-V 定位。此时关键问题不是它有没有“AI”宣传，而是外设管脚、内存、加密通信、OTA 和低电压行为能否满足目标板。
如果产品需要 5 GHz Wi-Fi、更多接口或不同封装，再针对新约束查其它型号；不能因为型号更新就假定旧候选不合适。若未来要让控制器直接承担 Thread/Zigbee 职责，应把 ESP32-C6 一类带 802.15.4 的芯片纳入比较，但先定义它是终端还是桥接/网关，不要只凭“支持 Matter”四个字定板。
2. 电池节点：H2 的价值在职责清晰
假设门磁或环境节点通过 Thread/Zigbee 与家庭网关通信，电池寿命优先，无须直接连 Wi-Fi。ESP32-H2 的 BLE 与 IEEE 802.15.4 能力贴合这个职责，官方文档并不把 Wi-Fi 列为其原生无线能力。这意味着产品系统图上必须画出承接上云与远程访问的网关；“节点能入 Thread 网络”不等于手机在外网可直接访问它。
如果需求改为“每个电池节点都独立连 Wi-Fi”，就已经换了架构问题。应重新比较电源预算、唤醒频率、连接时长与目标网络，而不是给 H2 添一行不存在的 Wi-Fi 配置。低功耗结论尤其不能从系列名称推出：睡眠电流还取决于模组、稳压器、传感器供电和唤醒策略，必须在目标板实测。
3. 语音终端：先分清唤醒、命令与对话
假设桌面终端需要按键或唤醒词、短命令、本地控制和云端对话。ESP32-S3 适合作为音频与联网一体化候选，但“语音支持”不是一个单项能力。唤醒词检测、离线命令识别、语音合成和开放式对话各有不同模型、内存、网络与语言要求。Espressif ESP-SR 的功能与支持芯片会随版本变化，选型时要固定组件版本、语言包、麦克风方案和目标延迟，再在实际板子上跑链路。
如果云端模型负责开放式对话，设备仍要决定断网时保留哪些命令、音频是否上传、回声抑制放在哪里。若产品需要大屏、摄像头和复杂动画同时运行，单颗 S3 可能不是合适的责任分配；可以改为处理芯片 + 无线芯片，但要把音频采集、UI、网络掉线和升级顺序写成明确接口。没有实测前，本文不承诺任何系列的语音准确率或端到端延迟。
4. 屏幕/视觉终端：P4 的无线空位不能藏在脚注里
假设终端要驱动较复杂的图形界面并接相机，且 Wi-Fi 为必需。ESP32-P4 的官方资料提供 MIPI、USB、SDIO、以太网等接口方向；它可承担更重的处理与显示职责。但官方 Wi-Fi 扩展文档明确说明 P4 没有原生 Wi-Fi，需通过另一颗 ESP32 等方式扩展无线能力。因此应在系统图中从一开始画出处理侧和连接侧，而不是等布局结束才“补一颗 Wi-Fi”。
双芯片方案要新增四个接口决策：应用数据如何跨芯片传输、连接侧故障如何恢复、两颗芯片的固件如何兼容升级、出厂及售后如何定位问题。若产品只是一块简单状态屏，不需要相机或复杂图形，这笔成本可能不划算；应回到较轻的单芯片候选重新测算。
评审时可要求团队给出一个具体故障演示：无线侧重启时，屏幕能否继续显示可信的本地状态？主处理侧升级失败后，连接侧是否还能被识别和恢复？这比只展示正常联网的 Demo 更能判断双芯片是否值得。上述问题是待验证清单，不代表本文已在 P4 开发板上完成测试。
最容易在评审会上漏掉的组合约束
“有协议”不等于“产品角色已经成立”
同一无线能力可以被做成终端、网关、桥接器或协处理器。ESP32-C6 支持 Wi-Fi、BLE 与 802.15.4，并不自动证明某块板、某版 SDK 与某个 Matter/Thread 角色已经被验证。确定产品角色后，核对对应 Espressif 示例、协议栈版本、射频共存、认证范围与 OTA 路径；未做联调的组合只能叫候选架构。
评审时可以把“同时支持”改写成一条会失败的测试：让目标板一边维持 Thread 通信，一边在 Wi-Fi 上传送预期业务数据，再触发一次 Wi-Fi 断线重连。记录 Thread 报文丢失、控制响应时间和恢复时长，并与产品允许的上限比较。若团队只能展示两种无线分别运行的演示，就还没有证明它们能承担同一台产品的并发职责；应先缩小功能承诺，或改用分工架构。这里给的是验收方法，不是 C6 的实测结果。
“主控 + 无线协处理器”要有故障合同
ESP32-P4 加无线 ESP32、或其它主控加 ESP32 连接芯片时，主控与无线侧之间不是一根“透明网线”。要定义谁保存 Wi-Fi 凭据、谁负责重连和时间同步、掉线期间本地功能如何处理、两边版本不一致时如何回滚。Espressif 的 P4 Wi-Fi expansion 与 ESP-Hosted 资料可用来核对支持的通信方式，但具体模组、管脚和吞吐需要按目标板验证。采购与固件团队都应拿到同一张接口责任表。
SDK 版本是选型输入，不是发布前补记
本稿把芯片事实锚到 Espressif 文档；具体项目应固定 ESP-IDF、ESP-SR 与无线扩展组件版本。官网的 latest 页面会变，示例可构建也不代表迁移旧产品无需改动。立项时记录现用 SDK、已投产板子的 Flash/PSRAM、加密与 OTA 机制，再评估迁移量。若升级只为获得一项尚未验证的功能，最好先做最小板级原型，而不是在生产固件上直接下注。
拿去开选型会的决策顺序
- 写出产品必须离线保留的功能，以及联网方式：Wi-Fi、BLE、Thread/Zigbee、以太网，哪些是必需、哪些只是未来可能。
- 画责任图：谁采集、谁控制、谁显示或处理音频、谁连接公网。H2 与 P4 的原生 Wi-Fi 空位要显式标出。
- 对每个候选组合核对目标模组数据手册：引脚、Flash/PSRAM、工作温度、供电、天线/认证与生命周期。不要用系列概览替代料号审核。
- 冻结目标 SDK 与组件版本，在实际板上跑一条最难的任务链：控制器测断网控制与 OTA；电池节点测真实待机；语音终端测目标语言、噪声和延迟；屏幕终端测图形/相机与连接侧并发。
- 把不满足的候选淘汰，并记录淘汰原因。只有数据和边界都能解释时，才把架构图变成 BOM。
如果问题只是“C3、S3、C6 三颗芯片做定制固件怎么比”，已有单芯片对比文更聚焦；如果问题是 P4 与 S3 的 HMI/视觉边界，也应看专门的屏幕选型文。本篇的新增答案是一台产品里怎样分配芯片职责，以及何时从单 SoC 转向主控加连接芯片。这项判断比系列排行更接近真正要签字的系统方案。
哪些情况下不该照着这张职责图下单
产品约束可能推翻上述所有默认候选。例如，目标地区的法规或认证清单不接受当前无线模组，系统必须改用已有认证方案；既有 PCB 只给一颗芯片留了尺寸与电源余量，双芯片方案便需要重新评估结构和供电；或者安全规范要求通信与控制完全隔离，单芯片方案即使算力够用也未必可接受。这些都不是 ESP32 系列性能表能替项目回答的问题。
同样，软件团队的现有资产会影响结果。已量产产品若有稳定的设备协议、生产烧录工具、远程升级与故障诊断，换到另一系列不只是移植几个 GPIO 定义。需要列出外设驱动、NVS 数据、加密密钥、分区表、bootloader 和出厂流程的迁移项，再把收益与回归成本放在同一张表。若收益只是“新型号看起来更先进”，保留原芯片可能是更稳妥的商业决策。
采购层面也不能只看 SoC 名称。具体模组的天线形态、Flash/PSRAM 配置、温度等级和供货周期决定能不能直接复用设计。比如语音样机上的 PSRAM 够用，不代表无 PSRAM 料号也能运行同一模型；开发板验证通过，也不代表自研板在相同 RF 环境下表现一致。因此正式定型要锁定模组完整料号、硬件版本与 SDK 版本，再做功能、射频和功耗验证。本文没有这些目标产品输入，结论只到候选架构为止。
选型会最后应留下两个可以被推翻的假设，而不只是一张推荐表。其一，“单芯片的空闲内存和升级空间足以覆盖目标功能”；其二，“双芯片的通信、重启与升级故障可以被产品团队定位和恢复”。分别指定验证板、固件版本、通过阈值与负责团队。若第一条在目标板失败，才考虑拆分职责；若第二条失败，也不能因为 P4 的显示能力更强就直接量产双芯片方案。
依据与未覆盖范围
- Espressif ESP-IDF：ESP32-C3 Get Started：C3 的平台与无线能力。
- Espressif ESP-IDF：ESP32-H2 Get Started 与 About：H2 的 BLE/802.15.4 定位。
- Espressif ESP-IDF：ESP32-P4 Get Started 与 Wi-Fi Expansion：P4 接口及外接无线方式。
- Espressif ESP32-C6 Hardware Design Guidelines：C6 无线组合；实际产品仍需冻结目标文档版本。
- Espressif ESP-SR：语音组件与版本支持，以目标 release 和板级配置为准。
本文没有目标产品原理图、BOM、功耗、并发、语音质量或量产验证记录；表格与情境只用于提出候选和排除错误架构，不构成实测排名或客户案例。
