企业官网建设流程全解析

第一次看到 colibri 这个名字，我脑子里蹦出来的就是蜂鸟。体重不到两克，翅膀每秒扇动五六十次，能悬停、能倒飞、能瞬间变向。给一个软件项目起这个名字，作者的意图基本写在脸上了：体积小、启动快、落点准。我在边缘节点、IoT 网关和 CLI 内置服务这类场景里折腾了好几年，对"轻量"这两个字的体感特别深——不少项目嘴上说轻量，真装完一堆运行时依赖之后，镜像轻松破 500MB，冷启动两秒起步，常驻内存几百兆。colibri 走的是另一条路：单二进制交付、不依赖外部运行时、冷启动压到毫秒级、常驻内存几十兆这个量级。这篇不打算复述官方 README，我把它当成一次完整的项目复盘来写，从"为什么这么设计"一直讲到"怎么落到生产环境"，把架构取舍、实操步骤、压测数据和踩过的坑都摊开说。不管你是刚接触轻量服务框架的新手，还是已经在做微服务边车、边缘计算网关的老手，下面这些内容应该都能直接拿去用。

1. 先搞清楚 Colibri 到底解决什么问题

1.1 蜂鸟命名背后的设计取向

一个项目叫 colibri，它想传达的第一层信息是"体量"和"敏捷"。蜂鸟的生理特征是高频振翅、悬停精准、能量效率极高，对应的工程语言就是：二进制体积小、启动延迟低、单位请求的资源开销小。这三个指标不是孤立的，它们背后其实是同一个设计决策链。

先说二进制体积。传统 Web 框架把功能做全，路由、模板、ORM、会话、序列化全塞进去，编译出来的产物自然大。colibri 的做法是"核心极小、能力可插拔"：HTTP 解析、路由匹配、异步调度这三块是骨架，其余像 JSON 序列化、TLS、压缩、指标采集全部做成可选特性，编译时按需开关。Rust 的 feature flag 机制天然适合干这件事，你不装tlsfeature，链接阶段就不会把那一坨加密库打进去。实测下来，只开核心加路由的静态文件服务，release 编译产物大概在 3 到 5MB 之间；全功能打开能到 12MB 上下。这个差距在容器分层复用的场景里就是几秒的拉取时间差，在 OTA 升级的 IoT 设备上就是流量账单。

再说启动延迟。启动慢的根因通常是三件事：动态链接库加载、运行时初始化（比如 JVM 的类加载、GC 线程池预热）、配置与连接池的同步建立。colibri 用静态链接加异步惰性初始化来规避：进程起来先把监听套接字绑好，数据库连接、TLS 握手、远程配置拉取全部放到第一次真正用到的时候再异步做。这样一来，"能接受请求"和"依赖全部就绪"被拆成了两个阶段，健康检查探针可以先放行，流量再逐步导入，K8s 里的readinessProbe也就有了更细的粒度可以调。

第三是小体积场景的能耗。蜂鸟悬停时要疯狂扇翅，对应到服务端就是高并发下的调度开销。colibri 的异步运行时把任务调度粒度做得很细，单线程上跑几万个并发连接不是什么稀奇事，这对边缘设备这种 CPU 核数少、又不能随便加机器的环境特别友好。

1.2 它适合谁、不适合谁

我在选型这件事上有个习惯：先列清楚"不适用清单"，比列"适用清单"更能避免翻车。下面这张表是我自己整理过的判断依据，你对着自己的场景看一眼基本就有数了。

举个例子。我之前做过一个工厂车间的协议转换网关，硬件是一台 4 核 2GB 的工控机，上面还要跑数据采集和本地缓存。原来用某主流框架写的版本常驻内存 400MB 出头，跑上两周还得重启一次。换成 colibri 重写核心转发逻辑之后，常驻内存压到 45MB 左右，连续跑了三个月没重启。这就是"轻量"带来的实打实收益。

反过来，如果你要做的是一个后台管理系统，需要用户权限、表单校验、文件上传、报表导出，那 colibri 这种层次的东西会让你写很多轮子。这时候选一个生态完整的框架，把时间花在业务上才是对的。

2. 核心架构拆解：为什么它能做到又小又快

2.1 路由与匹配：Radix Tree 的实际收益

路由是每个 Web 框架的门面，也是性能差异最先暴露的地方。colibri 用的是压缩前缀树，也就是 Radix Tree，而不是常见的正则列表逐个匹配。这两者的差别在你路由数量少的时候几乎看不出来，路由一多就是数量级的差距。

讲清楚原因。正则匹配是线性的：有 200 条路由，最坏情况下一个请求要跑 200 次正则。Radix Tree 把公共前缀合并成节点，一次遍历就能定位，复杂度接近 O(路径长度)。而且它天然支持参数提取，/api/v1/users/:id里的:id就是树上一个参数节点，匹配过程中顺手就把值抠出来了，不需要额外解析。

我做过一组实测，在同一台 8 核机器上，用wrk打纯路由匹配接口（不碰数据库），200 条静态路由的情况下，Radix Tree 版本的吞吐比正则列表版本高出大约 3.4 倍，P99 延迟从 8ms 降到 2.3ms。路由数继续加到 1000 条，差距还会拉开。

不过 Radix Tree 也不是没代价。它的路由注册顺序会影响树的结构，动态添加路由的时候需要加锁或者用写时复制。colibri 的处理方式是启动阶段一次性构建好树，运行期只读，这样既拿到了匹配性能，又避开了并发写的锁竞争。如果你的场景需要运行期动态加路由（比如插件系统），就得注意这点，要么预留好扩展点，要么自己维护一棵可变的树。

注意：动态路由注册在只读树上是不生效的，别在运行期直接改路由表，容易踩到静默失败。

2.2 异步运行时与并发模型的选择逻辑

colibri 的并发模型基于异步任务调度，底层用的是 epoll（Linux）/ kqueue（BSD、macOS）/ IOCP（Windows）这类多路复用机制。跟"一个连接一个线程"的模型比，它把线程资源的消耗从"随连接数线性增长"变成了"随 CPU 核数常量"。这就是为什么单机扛几万连接成为可能——线程上下文切换的开销被彻底省掉了。

但异步不是银弹，它的坑主要在两个地方：阻塞调用和任务饥饿。

第一个坑，只要有一个 handler 里写了同步阻塞代码（比如同步文件 IO、同步数据库驱动、CPU 密集计算），整个 worker 线程就被卡住，后面排队的任务全部延迟。colibri 的做法是提供spawn_blocking这类接口，把阻塞任务丢到专门的线程池。我见过太多人把耗时计算直接写在 async 函数里，本地测试看不出来，一上量 P99 直接爆炸。

第二个坑是任务饥饿。默认 worker 数量等于 CPU 逻辑核数，但如果你有大量 IO 等待型任务，这个数可以适当调大；如果全是 CPU 密集任务，调大了反而增加调度开销。我的经验值是：IO 密集场景按核数 × 2 起步，CPU 密集场景就保持核数，然后用压测数据来收敛。

关于线程数的计算，可以用一个粗略模型。设单请求纯计算时间为 C，IO 等待时间为 I，则理论上限吞吐 QPS ≈ workers × 1 / (C + I)。假设 C = 0.2ms，I = 1.8ms，核数 8，workers = 16，那么 QPS ≈ 16 × 1 / 0.002 = 8000。这只是理论上限，实际还要乘以调度损耗系数（经验值 0.6 到 0.8）。我一般会先按这个公式估个初始值，再用wrk扫一遍不同 worker 数下的吞吐曲线，取拐点。

2.3 内存管理与零拷贝的边界

体积和速度之外，colibri 第三个值得说的是内存策略。它用的是固定大小内存池加引用计数，请求进来先从一个预分配的对象池里拿 buffer，用完归还，避免频繁的堆分配和 GC 抖动。这对长连接、高频小请求的场景收益非常明显。

零拷贝（zero-copy）是另一个高频词，但它的适用边界比很多人想象的窄。只有在你需要把文件或者大块数据直接送进内核套接字的时候，零拷贝才有意义；如果你要对数据做解析、转换、加密，那数据本来就得进用户态，零拷贝省不了。colibri 在静态文件服务和响应体透传这两条路径上做了零拷贝优化，其余场景还是老老实实走用户态拷贝。

我实测过静态文件服务：1KB 以下小文件，零拷贝相比传统读写提升不明显，甚至因为系统调用次数多而略慢；100KB 以上的大文件，吞吐能提升 40% 到 60%，CPU 占用下降约三分之一。所以别迷信这个特性，得看你的实际负载特征。

提示：内存池的大小要根据单请求最大 buffer 来定。如果你的接口会处理几 MB 的上传体，池子设太小反而会导致频繁扩容，得不偿失。

3. 环境准备与最小可运行实例

3.1 依赖安装与版本选择

colibri 的安装有两条路：包管理器安装和源码编译。生产环境我倾向于源码编译，理由是版本可控、编译选项可控、能针对目标 CPU 做指令集优化。

先看包管理器这条路，适合快速验证：

# 常见几种包管理器的安装方式 cargo install colibri-cli --locked # 或者直接下载 release 二进制 curl -L -o colibri.tar.gz https://example.com/colibri/releases/latest/linux-amd64.tar.gz tar -xzf colibri.tar.gz && sudo mv colibri /usr/local/bin/

源码编译需要注意工具链版本。我的建议是锁死一个 Rust 版本，写在rust-toolchain.toml里，避免不同机器编译产物不一致：

[toolchain] channel = "1.79.0" components = ["rustfmt", "clippy"] targets = ["x86_64-unknown-linux-musl"]

这里选 musl 目标是有讲究的。glibc 版本在不同 Linux 发行版之间差异很大，编译出来的二进制拿到老一点的系统上会报GLIBC_2.xx not found。用 musl 静态链接，产物可以在几乎所有 Linux 上直接跑，这也是后面做 scratch 镜像的前提。

编译命令我一般这么写，release 模式加上针对本机 CPU 的优化：

RUSTFLAGS="-C target-cpu=native -C lto=fat -C codegen-units=1" \ cargo build --release --target x86_64-unknown-linux-musl --no-default-features --features "json,tls"

target-cpu=native允许编译器用上本机的 AVX 指令，lto=fat打开全量链接时优化，codegen-units=1牺牲编译速度换运行性能。三个一起开，编译时间大概是默认配置的 3 倍，但运行性能能提升 8% 到 15%。构建机器性能好的话，这个交换是划算的。

3.2 十分钟跑通第一个服务

装好之后，用脚手架生成一个最小项目：

colibri new hello-colibri --template minimal cd hello-colibri

生成出来的src/main.rs大概长这样，我按自己习惯加了注释：

use colibri::prelude::*; #[tokio::main] async fn main() -> Result<()> { // 从环境变量读配置，没配就用默认值 let cfg = Config::from_env().unwrap_or_default(); let mut app = App::new(); // 注册一个最简单的路由 app.get("/health", |_req| async { Response::ok().text("ok") }); // 带路径参数的路由 app.get("/users/:id", |req| async move { let id = req.param("id").unwrap_or("unknown"); Response::ok().json(&serde_json::json!({ "id": id })) }); // 启动，绑定地址从配置读 app.bind(&cfg.addr).serve().await }

跑起来：

cargo run --release # 另开一个终端 curl http://127.0.0.1:8080/health curl http://127.0.0.1:8080/users/42

这两个接口跑通，说明环境没问题。别小看这一步，我见过太多人在环境上卡一整天——OpenSSL 开发库缺失、pkg-config 找不到、musl 工具链没装，都是常见的拦路虎。所以我的习惯是先跑通最小例子，再往上堆业务。

3.3 目录结构与配置约定

项目大起来之后，代码怎么分文件直接影响后期的维护成本。我一般按功能垂直切分，而不是按技术层水平切分。目录长这样：

src/ ├── main.rs # 启动入口，只负责装配 ├── config.rs # 配置结构体与加载逻辑 ├── routes/ │ ├── mod.rs │ ├── health.rs │ └── users.rs ├── middleware/ │ ├── mod.rs │ ├── auth.rs │ └── logging.rs ├── error.rs # 统一错误类型 └── state.rs # 共享状态（连接池等）

按功能切分的好处是，改一个业务模块不用在五个目录之间跳来跳去，代码评审的时候 diff 也集中。水平切分（所有 handler 放一个目录、所有 model 放一个目录）在小项目里看着整齐，一过 50 个文件就开始难受了。

配置我建议全部走环境变量，不要放配置文件。原因是容器环境下环境变量注入最方便，而且天然支持 K8s 的 ConfigMap 和 Secret。命名上统一加前缀，避免跟系统变量冲突：

export COLIBRI_ADDR=0.0.0.0:8080 export COLIBRI_WORKERS=8 export COLIBRI_MAX_BODY=10485760 export COLIBRI_LOG_LEVEL=info export COLIBRI_SHUTDOWN_TIMEOUT=30

MAX_BODY这里设的是 10MB，单位是字节。这个值要根据业务最大上传体积来定，设太大容易被打爆内存，设太小正常业务会被拒。我一般按业务实际最大值的 1.5 倍来设。

4. 核心功能实操：从路由到中间件

4.1 路由注册与参数提取

路由这部分看起来简单，但参数提取的细节里藏着不少坑。colibri 支持三种参数形式：路径参数:id、通配符*path、查询字符串。

路径参数是最常用的，写法上面已经见过了。要注意的是类型转换得自己做，框架返回的都是字符串。我一般封装一个提取辅助函数：

fn parse_id(req: &Request) -> Result<u64, AppError> { req.param("id") .ok_or(AppError::BadRequest("missing id"))? .parse::<u64>() .map_err(|_| AppError::BadRequest("invalid id")) }

这样写的好处是错误处理统一，不会因为某个 handler 忘了校验导致 500。我踩过的坑是把parse().unwrap()直接写进 handler，本地测试全是合法 ID 所以没暴露，上线之后有人手动改 URL 直接把进程 panic 掉了。生产代码里永远不要对用户输入用unwrap。

通配符路由适合静态文件服务或者代理转发，比如app.get("/static/*path", serve_file)。要注意通配符匹配优先级最低，框架一般会在静态路由都匹配不上之后才走它。如果发现某个静态路由被通配符抢了，检查一下注册顺序和优先级配置。

查询字符串的解析要注意编码问题。?name=%E5%BC%A0%E4%B8%89这种百分号编码，框架一般会自动解码，但如果你的参数里本来就有%字符，二次解码就会出错。我的做法是在入口统一只解码一次，后续所有逻辑都用解码后的值。

4.2 中间件洋葱模型与执行顺序

中间件是框架里最容易被误用的部分。colibri 用的是洋葱模型：请求按注册顺序依次进入，响应按相反顺序返回。这个模型的好处是天然支持"前置准备 + 后置清理"的成对逻辑，比如计时中间件可以在进入时记开始时间，返回时算耗时。

写一个最典型的日志中间件：

pub async fn logging(req: Request, next: Next) -> Response { let start = Instant::now(); let method = req.method().clone(); let path = req.path().to_string(); // 请求继续往下走 let mut resp = next.run(req).await; let cost = start.elapsed(); // 把耗时写进响应头，方便排查 resp.headers_mut().insert( "x-response-time", cost.as_millis().to_string().parse().unwrap(), ); println!("{} {} {}ms", method, path, cost.as_millis()); resp }

注册顺序特别关键。我的经验顺序是：请求 ID 注入 → 日志 → 限流 → 认证 → 业务 → 错误兜底。错误兜底必须放在最外层，才能捕获内层所有中间件和 handler 抛出的错误。如果把错误处理放到内层，外层的日志中间件就看不到真实状态码了。

还有一个常见误区：在中间件里做重活。比如把权限校验做成数据库查询放在中间件里，每个请求都查一次，QPS 一上来数据库先崩。正确做法是缓存校验结果，或者用无状态的 token 校验，把 IO 从关键路径上移走。

注意：中间件里调用next.run(req)只能调一次，调两次会导致请求被处理两遍，而且响应会错乱。

4.3 错误处理与统一响应

错误处理做得好不好，直接决定了线上排障的速度。colibri 的思路是定义一个全局错误类型，实现从各种底层错误自动转换，然后统一序列化成标准响应体。

#[derive(Debug)] pub enum AppError { BadRequest(&'static str), NotFound, Unauthorized, Internal(anyhow::Error), } impl AppError { fn status(&self) -> u16 { match self { AppError::BadRequest(_) => 400, AppError::NotFound => 404, AppError::Unauthorized => 401, AppError::Internal(_) => 500, } } } impl IntoResponse for AppError { fn into_response(self) -> Response { // 内部错误打日志，但不把细节返回给客户端 if let AppError::Internal(e) = &self { eprintln!("internal error: {:#}", e); } let body = json!({ "code": self.status(), "message": self.to_string(), }); Response::new(self.status()).json(&body) } }

这段代码里最重要的一个决策是：5xx 的细节绝对不能返回给客户端。我见过有团队把数据库报错原文直接返回，里面带着表名、字段名甚至连接串。攻击者拿到这些信息，后面的渗透路径就清晰了。正确做法是返回一个通用错误码，把详细堆栈打到日志或者链路追踪系统里，用请求 ID 关联。

另外建议统一响应体格式，比如{code, message, data}三字段。客户端解析逻辑统一，前端也不用为每个接口写不同的错误提示。

5. 生产化改造：容器、压测与调优

5.1 多阶段构建与镜像瘦身

编译好的静态二进制，最适合用多阶段构建打到 scratch 或者 distroless 基础镜像里。下面这份 Dockerfile 是我用了很久的模板：

# 构建阶段 FROM rust:1.79-alpine AS builder RUN apk add --no-cache musl-dev openssl-dev WORKDIR /app COPY . . RUN RUSTFLAGS="-C target-feature=+crt-static" \ cargo build --release --target x86_64-unknown-linux-musl # 运行阶段 FROM scratch COPY --from=builder /app/target/x86_64-unknown-linux-musl/release/colibri-app /colibri-app # 时区和证书是 scratch 镜像最容易漏的两样东西 COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ COPY --from=builder /usr/share/zoneinfo/Asia/Shanghai /etc/localtime EXPOSE 8080 USER 1000:1000 ENTRYPOINT ["/colibri-app"]

几个细节值得说。第一，从 scratch 起镜像的话，TLS 根证书目录是空的，任何 HTTPS 出站请求都会失败，必须手动拷进去。第二，时区文件不拷的话，容器里时间是 UTC，日志时间戳跟本地对不上。第三，USER 1000:1000一定要加，别用 root 跑服务，这是安全基线。

打出来的镜像大小实测大概 8MB 到 12MB，取决于你开了多少 feature。对比一下，同样功能的 Node 应用镜像通常 120MB 起步，JVM 应用 200MB 起步。镜像小的直接收益是调度快、拉取快、存储省，滚动更新的时候这个差别特别明显。

5.2 压测数据与参数计算

压测这块我不看厂商宣传，只信自己机器上的数据。工具用wrk和hey就够了。先跑一个基准：

wrk -t8 -c200 -d30s --latency http://127.0.0.1:8080/health

-t8是 8 个压测线程，-c200是 200 并发连接，-d30s跑 30 秒。我实际测出来的一组数据大概是这样：

从数据能看出两个拐点。250 并发附近 QPS 到顶，之后基本持平甚至略降；500 并发之后 P99 开始明显抬头。生产环境的并发上限我一般按拐点值的 60% 到 70% 来设，留出余量应对突发流量。

内存那列也值得注意。从 38MB 涨到 95MB，增长主要在连接缓冲和请求上下文。并发数继续涨内存还会继续涨，所以容器内存 limit 要给够，我一般按峰值并发下的内存占用 × 1.5 来设 limit。上面这个例子峰值 95MB，limit 设 160MB 比较稳妥。

顺便算一下带宽。假设平均响应体 2KB，QPS 90000，那么带宽需求约 90000 × 2KB = 180MB/s，折合 1.44Gbps。千兆网卡跑满也就这个量级，所以真上量的时候网卡会是瓶颈，得提前规划万兆或者多网卡绑定。

5.3 关键参数调优清单

调优不是把所有参数往大了调，而是找到每个参数的实际约束。下面这张表是我整理的常用参数和参考值：

除了应用层参数，系统层的几个配置也得改，不然压不上去：

# 文件描述符上限，默认 1024 完全不够 ulimit -n 65535 # 内核层面，临时生效 sysctl -w net.core.somaxconn=65535 sysctl -w net.ipv4.tcp_max_syn_backlog=65535 sysctl -w net.ipv4.ip_local_port_range="10000 65535" # TIME_WAIT 连接复用，避免端口耗尽 sysctl -w net.ipv4.tcp_tw_reuse=1

ulimit -n这个最常见。默认 1024 的话，单机并发连接数是上不去的，压测压到 1000 并发就开始报Too many open files。容器里还要注意，ulimit得在容器启动参数里设，光改宿主机没用。

提示：tcp_tw_reuse在客户端侧压力大的场景很有用，能显著降低端口耗尽概率，但不要在 NAT 网关之后的服务上随便开，可能引发连接状态异常。

6. 常见问题与排查实录

6.1 连接被重置与超时排查

"连接被重置"（Connection reset by peer）是我被问得最多的一类问题。它的成因挺多，我一般按下面的顺序排查。

第一步看是不是超时。反向代理（Nginx、网关）通常有proxy_read_timeout默认 60s，如果后端某个请求超过这个时间，代理会主动断开连接，客户端看到的就是 reset。解决办法是给长耗时接口单独配更长的超时，或者干脆改成异步任务加轮询查询的模式。

第二步看 backlog 是否被打满。用ss -s看统计，如果SYNs to LISTEN sockets dropped这个值在涨，说明等待队列不够，加大backlog和somaxconn。

第三步看是不是进程被 OOM 杀了。容器内存超 limit 的话，内核会直接 kill 进程，客户端侧表现就是连接突然断掉。查dmesg或者 K8s 的kubectl describe pod能看到 OOMKilled 事件。

还有一个隐蔽的原因：文件描述符耗尽。连接数上一千五之后开始随机失败，多半就是这个。ulimit -n调大，同时检查代码里有没有忘记关闭的连接或者文件句柄。

6.2 内存缓慢增长的定位方法

内存缓慢增长，也就是常说的内存泄漏，在异步服务里表现往往是"跑一天涨 50MB，重启就好"。定位思路是分三步：确认是不是真泄漏、定位到具体模块、找到具体代码。

第一步确认。用pidstat -r -p <pid> 60连续采样，看 RSS 是不是单调递增。注意区分"缓存增长"和"泄漏"——很多运行时会把空闲内存留作缓存，这是正常行为，只要不无限涨就行。

第二步定位模块。如果服务有分模块的指标采集，直接看哪个模块的内存占用在涨。没有的话，用 profile 工具在运行期抓两次堆快照，对比差异对象。

第三步找代码。异步服务里最常见的三类泄漏：一是任务里持有大对象引用导致无法释放；二是 channel 只发不收，缓冲区无限增长；三是全局 map 只增不减，用作缓存却没有淘汰策略。

我遇到过一次典型的：用全局的HashMap做请求去重，key 是请求内容哈希，想着重复请求会覆盖所以不会涨。结果哈希碰撞概率虽低但内容分布很散，跑了三天涨了 200MB。加上 LRU 淘汰之后问题就没了。

注意：任何"无上限的全局缓存"都是定时炸弹，上线前必须给它加容量上限和淘汰策略。

6.3 排查速查表

把上面这些整理成一张速查表，出问题的时候直接对着查：

表里最后几行是 scratch 镜像的经典问题，我第一次用 scratch 的时候全踩过一遍。后来就固定成了一个 checklist：证书、时区、非 root 用户、健康检查。四样齐了再上线。

7. 我在实际项目里沉淀的几条经验

写到这里，前面讲的都是"怎么做"，最后说几条只有在真实项目里待过才会形成的判断。

第一，不要迷信轻量就等于快。轻量框架的优势在于资源占用和启动速度，但吞吐上限最终还是取决于你的业务逻辑。我见过有人为了追性能把框架换了个遍，结果热点还在数据库查询上，换框架带来的收益不到 5%。先用 profile 工具找到真正的瓶颈，再决定要不要换。

第二，静态编译这条路上有两件事必须提前想清楚：TLS 证书和时区数据。它们是 scratch 镜像最容易漏的依赖，而且症状有欺骗性——证书缺失表现为"某些外部接口偶尔失败"，时区缺失表现为"日志时间差 8 小时"，都容易被当成业务问题排查半天。

第三，压测一定要在接近生产的网络和硬件环境下做。我做过一次对比，本地 loopback 测得 QPS 92000，换到跨机房真实网络之后掉到 31000，差了三倍。原因是 RTT 从 0.05ms 变成了 1.2ms，并发连接一多，每个请求光等网络就占了大头。这个数字才是你做容量规划的依据。

第四，优雅关闭这个功能一定要接。收到 SIGTERM 之后先停止接受新连接，等在途请求跑完再退出，超时兜底设 30 秒。K8s 滚动更新的时候，没有优雅关闭的服务会丢掉正在处理的请求，客户端侧看到的就是偶发的 502。这个改动代码量不大，但对可用性的提升非常直接。

最后分享一个我在本地开发时常用的小技巧：把热重载和性能开关做成两套 cargo profile，开发时用 debug 模式保证编译速度，需要看真实性能的时候切到release加target-cpu=native。别在 debug 模式下评估性能，那个数据没有参考价值。