编译时裁剪：通过配置宏定义移除不需要的密码套件、协议版本和扩展功能
好，我们直接进入正题。嵌入式设备的内存就那么点，TLS 协议栈却像个贪吃蛇，什么都想吞进去。你想想看，一个完整的 OpenSSL 编译出来，动辄几兆字节，这在服务器上不算什么，但在只有几百 KB Flash 的 MCU 上，简直就是灾难。
所以，编译时裁剪是内存优化的第一道防线。说白了，就是「不要的东西，一开始就别编译进去」。这比运行时动态卸载要高效得多——代码根本不会出现在固件里，连占位的机会都没有。
为什么要在编译时动手？
我见过不少开发者，项目做到一半发现 Flash 不够了，然后开始各种「骚操作」：动态加载、运行时卸载、甚至手动改库代码。说实话，这些方法要么不稳定，要么工作量巨大。
我个人习惯是，在项目启动阶段就把裁剪方案定下来。因为编译时裁剪有几个天然优势：
- 零运行时开销——被裁掉的代码根本不存在
- 安全性提升——减少攻击面，少一个功能少一个漏洞
- 编译速度更快——少编译几万行代码，你试试看
核心原则：只编译你真正需要的功能。不要抱着「万一以后要用」的心态，嵌入式开发没有「万一」的余量。
密码套件的裁剪——最立竿见影的优化
密码套件是 TLS 协议栈里最占空间的部分。一个完整的 OpenSSL 支持上百种密码套件，但你的设备可能只需要两三种。我在一个智能电表项目里遇到过，光是密码套件的初始化表就占了 80KB Flash，而实际通信只用到了 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 这一个套件。
常见的 TLS 库都提供了宏定义来控制密码套件的编译。以 Mbed TLS 为例：
// 在 mbedtls_config.h 中配置
// 只保留需要的密码套件
#define MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED
#define MBEDTLS_CIPHER_AES_128_GCM
#define MBEDTLS_MD_SHA256
// 明确禁用不需要的
#undef MBEDTLS_KEY_EXCHANGE_RSA_ENABLED
#undef MBEDTLS_KEY_EXCHANGE_DHE_RSA_ENABLED
#undef MBEDTLS_CIPHER_AES_128_CBC
#undef MBEDTLS_CIPHER_AES_256_CBC
#undef MBEDTLS_CIPHER_CHACHA20_POLY1305
#undef MBEDTLS_MD_SHA1
#undef MBEDTLS_MD_MD5你看，这样一配置，编译出来的代码体积能减少 60% 以上。我曾经在一个项目里，通过裁剪密码套件，把 Mbed TLS 从 180KB 降到了 45KB。
我的经验：先列出你的设备必须支持的密码套件列表。通常不超过 3 个。然后逐个禁用其他所有套件。如果编译报错，说明有依赖关系没处理好，再逐个加回来。
协议版本的裁剪——老版本该扔就扔
TLS 1.0 和 TLS 1.1 早就被 RFC 宣告废弃了。但很多嵌入式库为了兼容性，默认还是把它们编译进去。这不仅是安全问题，也是内存浪费。
我建议只保留 TLS 1.2 和 TLS 1.3。如果你的设备需要连接老旧服务器，最多再加个 TLS 1.1，但 TLS 1.0 真的可以扔了。
以 WolfSSL 为例：
// 在 settings.h 或 user_settings.h 中配置
// 启用 TLS 1.2 和 1.3
#define WOLFSSL_TLS13
#define NO_OLD_TLS
// 禁用 TLS 1.0 和 1.1
#undef WOLFSSL_ALLOW_TLSV10
#undef WOLFSSL_ALLOW_TLSV11这样做的好处很明显：
- 减少约 15-20KB 的协议处理代码
- 消除 POODLE、BEAST 等老旧攻击的威胁
- 简化握手流程，连接建立更快
注意：如果你裁剪了 TLS 1.3，记得检查你的密码套件是否支持 1.3 的密码族。TLS 1.3 只支持 AEAD 类密码，不支持 CBC 模式。我曾经踩过这个坑——裁剪了 1.3 的密码套件，结果 1.3 握手一直失败。
扩展功能的裁剪——别让「锦上添花」变成「雪上加霜」
TLS 有很多扩展功能，比如 SNI（服务器名称指示）、ALPN（应用层协议协商）、Session Ticket、OCSP Stapling 等等。这些功能在特定场景下很有用，但如果你用不到，它们就是纯粹的内存浪费。
我整理了一个常见的扩展功能裁剪清单：
| 扩展功能 | 典型体积 | 裁剪条件 |
|---|---|---|
| SNI | ~4KB | 单服务器场景可裁 |
| ALPN | ~3KB | 只使用 HTTP/1.1 可裁 |
| Session Ticket | ~8KB | 短连接场景可裁 |
| OCSP Stapling | ~6KB | 使用固定证书可裁 |
| Renegotiation | ~5KB | 绝大多数场景可裁 |
| Max Fragment Length | ~2KB | 使用默认 MTU 可裁 |
在 Mbed TLS 中，禁用扩展功能的方式也很直接：
// 禁用不需要的扩展
#undef MBEDTLS_SSL_SESSION_TICKETS
#undef MBEDTLS_SSL_ALPN
#undef MBEDTLS_SSL_SERVER_NAME_INDICATION
#undef MBEDTLS_SSL_RENEGOTIATION
#undef MBEDTLS_SSL_MAX_FRAGMENT_LENGTH避坑指南：我曾经在一个项目里裁剪了 SNI，结果设备连接云服务器时一直失败。查了半天才发现，那个云服务器要求客户端必须发送 SNI 扩展。所以，裁剪之前一定要确认服务端的要求，别省了内存丢了功能。
整体裁剪策略——一张图看懂
下面这张图展示了编译时裁剪的整体流程和决策点。你可以把它当作裁剪工作的路线图：
裁剪后的验证——别省了内存丢了功能
裁剪完成后，一定要做两件事：
- 编译测试——确保没有因为裁剪导致编译错误。有些功能之间有隐式依赖，比如某些密码套件依赖特定的哈希算法。
- 功能测试——用真实的服务器进行握手测试。我建议准备一个测试矩阵，覆盖所有保留的密码套件和协议版本组合。
我的小技巧：在裁剪过程中，每次只禁用一组功能，然后编译测试。这样如果出问题，很容易定位是哪个裁剪导致的。不要一次性禁用几十个宏，然后面对一堆编译错误无从下手。