这块 1.3 英寸屏幕有微弱背光，ESP32-S3 也能正常运行程序，串口会不断打印切换画面的日志，但屏幕就是没有一个像素出现。排查到后面，我一度认为它已经坏了，于是换了一块 ST7735 绕过去继续做项目。
后来，自媒体平台的一位网友提醒我：先确认屏幕的具体版本和驱动配置。这个提醒把问题从“屏幕是不是坏了”重新拉回到一个更具体的方向——驱动芯片、分辨率、接口和 SPI 通信模式，是否真的逐项匹配？
“屏幕不亮”并不一定是坏了
我最初说的是“屏幕不亮”，但继续观察后发现，背光其实有微光，只是没有像素画面。这两个现象不能混为一谈：
-
没有背光：优先检查 VCC、GND、BLK 和供电。
-
有背光、没有像素：背光供电并不等于显示控制器已经正确收到初始化命令和像素数据，还要继续检查复位、接线、驱动和 SPI 通信。
在我的环境里，串口日志和按钮切换都正常，只能证明 ESP32 正在运行程序，不能证明屏幕真的收到了可识别的 SPI 数据。这也是排查过程中最容易产生的错觉：程序在跑，不代表显示链路已经通了。
驱动芯片匹配，不等于通信配置全部匹配
屏幕背面的型号是 GMT130-V1.0。实物丝印和厂商产品资料都指向同一组信息：1.3 英寸、240×240、ST7789、SPI 接口。厂商页面还把它列为 4-wire SPI 模块：GMT130-V1.0 厂商产品页。
GMT130-V1.0 模块背面标注了 240×240、ST7789 与 SPI 接口。
因此，原程序中的以下三项其实是匹配的：
-
使用 Adafruit_ST7789：匹配 ST7789 驱动芯片。
-
调用 tft.init(240, 240, …)：匹配 240×240 分辨率。
-
设置 TFT_CS = -1：匹配这块没有独立 CS 引脚的七针模块。
真正遗漏的是另一层：怎样把数据按屏幕能识别的时序发出去。SPI mode 决定时钟空闲时的高低电平，以及数据在哪个时钟边沿变化、在哪个边沿采样。Espressif 的 SPI 文档也把时钟、MOSI 和片选分别列为 SPI 总线信号，并说明 ESP32 的 SPI 引脚可以在初始化时配置：Arduino-ESP32 SPI API。
换句话说，ST7789 回答的是“应该和哪一类控制器对话”，SPI_MODE0 / SPI_MODE3 回答的是“对话时钟和数据怎样配合”。前者选对，并不能自动保证后者也对。
五参数构造函数，让我以为已经测试了 Mode 3
原来的纯色诊断程序使用了 Adafruit_ST7789 的五参数构造函数：
Adafruit_ST7789 tft(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);
tft.init(240, 240, SPI_MODE0);静态检查 Adafruit 的官方源码后，我才看懂：这个五参数构造函数选择的是软件 SPI。在我安装的 Adafruit GFX 1.12.6 中，软件 SPI 分支自行拉动 SCK 和 MOSI；传给初始化函数的 SPI mode 只在硬件 SPI 的 SPISettings 路径中应用。相关实现可以在 Adafruit_SPITFT 1.12.6 源码 和 Adafruit_ST7789 1.11.0 源码 中核对。
这意味着，在当前库版本和写法下，只把代码里的 SPI_MODE0 文本换成 SPI_MODE3，并不能证明引脚上真的产生了 Mode 3 时序。要验证这个假设，需要切换到会实际应用 SPI mode 的硬件 SPI 构造路径。
保持接线不动，建立硬件 SPI Mode 3 最小程序
新的诊断程序保留原来的引脚映射：
排查时使用的 ESP32-S3 与七线 GMT130-V1.0 接线。
程序只改变通信路径和 mode，并把频率设为较保守的 1 MHz：
Adafruit_ST7789 tft(&SPI, TFT_CS, TFT_DC, TFT_RST);
SPI.begin(TFT_SCLK, -1, TFT_MOSI, TFT_CS);
tft.init(240, 240, SPI_MODE3);
tft.setSPISpeed(1000000);随后程序每两秒只做一件事：依次填充红、绿、蓝、白、黑，并在串口打印当前颜色。这样可以同时回答两个问题：ESP32 到底运行了哪个版本的程序，以及屏幕是否真的收到像素数据。
Mode 0 黑屏，Mode 3 点亮
把几次实际测试放在一起，对比才变得清楚：
| 测试路径 | 通信时序 | 实测结果 |
|---|---|---|
| 早期硬件 SPI 表情程序 | Mode 0 | 有微光，无像素画面 |
| 软件 SPI 纯色程序 | 当前库路径固定为 Mode 0 形态 | 串口循环正常，屏幕无像素 |
| 新硬件 SPI 纯色程序 | 实际应用 SPI_MODE3，1 MHz | 红、绿、蓝、白、黑正常循环 |
新程序上传后，这块曾被我判断为损坏的屏幕第一次显示出了完整纯色。
改用硬件 SPI 并设置 SPI_MODE3 后，GMT130-V1.0 显示红色纯色画面。
我保持代码和七根接线不动，拔掉 USB，确认开发板断电后重新接入。屏幕再次循环显示五种颜色，串口也连续输出：
DIAG MODE3 frame: RED
DIAG MODE3 frame: GREEN
DIAG MODE3 frame: BLUE
DIAG MODE3 frame: WHITE
DIAG MODE3 frame: BLACK因此，本次结论不是“碰巧亮了一次”，而是在当前硬件、库版本、引脚和接线条件下完成了断电重启复测。
如果遇到同样现象，可以怎样缩小范围
-
先说清现象。区分完全无光、有背光无像素、颜色错误、偏移或花屏。
-
确认完整模块型号。不要只凭“1.3 英寸”或“240×240”猜驱动，优先查看背面丝印和厂商资料。
-
把匹配项拆开。分别检查驱动芯片、分辨率、接口类型、CS 结构、引脚映射和 SPI mode。
-
用串口确认程序身份。日志只能证明程序运行，不能代替屏幕结果，但能避免把旧程序误当成新测试。
-
改成最小纯色程序。先去掉按钮、表情和业务逻辑，每次只显示一种纯色。
-
确认 mode 是否真的被库应用。不要只看参数名，要看当前构造函数走软件 SPI 还是硬件 SPI。
-
尽量只改变一个假设。保持接线、引脚、驱动和分辨率不动，再比较 Mode 0 与 Mode 3。
-
成功后断电复测。确认重启后仍能恢复，才把结论从单次成功提升为已复测。
AI 时代，领域知识仍然决定你能提出什么问题
这次能回到驱动和通信配置，是因为公开学习时，有专业经验的网友提醒我从这个方向定位。我没有硬件基础时，不知道应该怎样向 AI 描述问题、追问构造函数和 SPI mode，只能根据“始终不显示”得出“屏幕坏了”的判断。
公开学习让我获得了专业人士的指点，加快了解决问题的速度；但我也需要补基础知识。只有对供电、引脚、驱动和通信有基本概念，下一次遇到问题时，我才知道应该观察什么、怎样向 AI 提问，以及怎样验证它给出的建议。
这不是说使用 AI 前必须先成为硬件专家。更实际的做法是：一边做项目，一边把每次卡住自己的概念补起来。AI 可以快速生成候选答案，领域知识则帮助我把模糊现象变成可检查的问题，并判断哪一个答案值得上电验证。
结论边界
另外，结果照片直接证明的是红色帧；完整五色循环由目视确认、连续串口日志和断电重启复测共同支持。厂商示例代码可见：GMT130-V1.0 规格与示例程序 PDF。