在本站中

本站是开源的，仓库在 yuxuetr/rustineverything。主 workspace 自己没有一行代码直接调 rustls，它是被三个依赖带进来的：sqlx（经 sea-orm）、lettre、reqwest。网关 crates/gateway 是独立的 workspace，用 pingora 的 OpenSSL 后端，锁文件里没有 rustls。

这一部分按框架仓库 main 分支的提交 363dd8f（2026-10-29）讲，看的是发布镜像那次服务端构建（--no-default-features --features accounts，加上 dx 的 server）实际编进来的依赖。站点代码只读不改，所有实验都在拷贝和镜像 crate 上做。

1. 本站的 rustls：cargo tree 显示 rustls 只开了 ring、std、tls12、logging，锁文件里没有 aws-lc-rs，也没有 rustls-native-certs。reqwest 0.12.28 同时编进 native-tls 和 rustls，Client::builder().build() 选的是 native-tls：本机实测它发出的是 Security.framework 的 TLS 1.2 ClientHello，Linux 上换成系统的 OpenSSL；站点的四处 reqwest 客户端都走这条路。sqlx 和 lettre 才是真正的 rustls 用户，ClientHello 236 字节、只带一个 X25519 共享，根证书都是编进二进制的 webpki-roots。进程里没有装默认 provider；三个库各自指定或兜底到 ring，所以哪天某个依赖打开 rustls 的默认 feature，它们照常工作，只有直接调 ClientConfig::builder() 的代码会 panic。

flowchart TB
  app["app 服务端"] --> sqlx["sqlx"]
  app --> lettre["lettre"]
  app --> reqwest["reqwest"]
  sqlx --> rr["rustls + ring"]
  lettre --> rr
  reqwest --> ntls["native-tls"]
  reqwest -.-> rr
  ntls --> ossl["系统 OpenSSL"]
  gw["网关 pingora"] --> vend["内置 OpenSSL"]