io_uring 深度解剖：Linux 异步 I/O 的性能王者，为何又被 Google 全线封禁——从 SQE/CQE 环形队列到零拷贝、SQPOLL 与安全攻防

一、背景：我们到底在跟什么样的 I/O 模型死磕

写过高并发服务端的人，对 Linux I/O 的进化史大概都有一种「痛并快乐着」的记忆。

最早我们用 read()/write() 阻塞式硬扛，一个连接一个线程，几千并发就把调度器压垮。后来有了 select/poll，再后来 epoll 一统江湖，撑起了 nginx、Redis 这一代高性能服务的半壁江山。epoll 的模型是「就绪通知」（readiness-based）：内核告诉你「这个 fd 可读了」，然后你再自己去 read()。

问题就出在这个「你再自己去 read」上。

epoll 只解决了「什么时候该做 I/O」，没解决「做 I/O 本身的开销」。每一次 read()/write() 依然是一次完整的系统调用（syscall），依然要陷入内核态、拷贝数据、返回用户态。在 Meltdown/Spectre 之后，内核为了防御旁路攻击加上了 KPTI（页表隔离），syscall 的成本进一步上升——一次上下文切换动辄几百纳秒。当你的服务每秒要处理百万级请求时，光是 syscall 的开销就能吃掉你 20%~30% 的 CPU。

更别提 epoll 对文件 I/O 几乎无能为力：普通磁盘文件在 epoll 里永远是「就绪」的，你根本没法用 epoll 做真正的异步磁盘读写。历史上 Linux 有过一套 aio（io_submit/io_getevents），但那套 API 设计得极其难用，而且只对 O_DIRECT 有效，缓冲 I/O 直接退化成同步阻塞，被 Linus 骂过无数次。

于是 2019 年，块层大神 Jens Axboe 在 Linux 5.1 里端出了 io_uring。它的野心不是「再做一个 epoll」，而是要成为统一的、真正的异步系统调用框架——磁盘、网络、文件元数据操作，全都能异步化，而且把 syscall 开销压到接近于零。

这篇文章我们就把 io_uring 从里到外扒一遍：环形队列的内存模型、SQE/CQE 的生命周期、liburing 的正确用法、SQPOLL / 注册缓冲区 / 链式操作 / multishot / 零拷贝发送这些进阶特性，最后再聊聊它为什么性能炸裂却被 Google 在 ChromeOS、Android、GKE 里全线封禁，以及生产环境到底该怎么权衡。

二、核心思想：把「系统调用」变成「往队列里丢任务」

io_uring 的名字拆开来看：io + user + ring。核心是两个在用户态和内核态之间共享的环形缓冲区（ring buffer）：

• SQ（Submission Queue，提交队列）：用户态往里放「我要做什么 I/O」，元素叫 SQE（Submission Queue Entry）。
• CQ（Completion Queue，完成队列）：内核往里放「这个 I/O 做完了，结果是什么」，元素叫 CQE（Completion Queue Entry）。

关键词是共享内存。这两个 ring 通过 mmap 映射到用户进程地址空间，用户态和内核态直接读写同一块物理内存，不需要每次都靠 syscall 传参、拷贝。

传统模型：read() = 一次 syscall = 一次陷入 + 一次返回。
io_uring 模型：填一个 SQE 到共享内存 → （批量地）敲一次 io_uring_enter 通知内核 → 内核异步执行 → 结果写进 CQ → 用户态直接从共享内存读 CQE。

这里有两个降本的杠杆：

1. 批处理（batching）：你可以一口气填 100 个 SQE，然后只调用一次 io_uring_enter，一次 syscall 提交 100 个 I/O。syscall 的固定开销被摊薄到 1/100。
2. 无 syscall 提交（SQPOLL）：更极端的模式下，内核起一个专门的轮询线程盯着 SQ，你只要把 SQE 写进共享内存，内核线程自己就捞走执行了——连 io_uring_enter 都省了，整个提交路径零 syscall。

这就是 io_uring 性能的第一性原理：用共享内存 + 批处理，把「每次 I/O 一次 syscall」摊薄成「每批 I/O 一次甚至零次 syscall」，同时天然异步，磁盘和网络一视同仁。

三、内存模型：三个 mmap 区域与那些「魔鬼在细节里」的指针

要真正理解 io_uring，必须看清它的内存布局。io_uring_setup(2) 返回一个 fd，然后你用这个 fd 去 mmap 出三块区域（在较新内核里 SQ ring 和 CQ ring 可以合并成一次 mmap）：

SQ Ring:  head, tail, ring_mask, ring_entries, flags, dropped, array[]
CQ Ring:  head, tail, ring_mask, ring_entries, overflow, cqes[]
SQEs:     独立的一块数组，真正的 SQE 结构体存放处

有意思的是 SQ 的设计：SQ ring 里的 array[] 存的是索引，指向真正的 SQE 数组。这是一层间接（indirection），目的是让用户态可以灵活地复用、乱序填充 SQE，而不必和 ring 的顺序强绑定。

head 和 tail 是环形队列的经典双指针：

• 用户态生产 SQE：递增 SQ 的 tail。
• 内核消费 SQE：递增 SQ 的 head。
• 内核生产 CQE：递增 CQ 的 tail。
• 用户态消费 CQE：递增 CQ 的 head。

由于是共享内存里的并发读写，这里必须用**内存屏障（memory barrier）**来保证顺序性——用户态写完 SQE 内容后，必须有一个 smp_wmb() 语义的屏障，再更新 tail，否则内核可能读到「tail 已更新但 SQE 内容还没写完」的脏数据。反过来读 CQE 时也要有读屏障。

这些屏障细节非常容易写错，也是为什么 Jens Axboe 同时维护了一个用户态封装库 liburing——把这些屏障、mmap、head/tail 管理全封装好。除非你在写底层框架，否则永远用 liburing，不要裸调三个 syscall。 下面的代码全部基于 liburing。

底层的三个系统调用只有：

• io_uring_setup(entries, params)：创建 ring，返回 fd。
• io_uring_enter(fd, to_submit, min_complete, flags, sig)：提交 SQE 并/或等待 CQE。
• io_uring_register(fd, opcode, arg, nr_args)：注册缓冲区、文件、eventfd 等资源。

四、第一个能跑的例子：用 io_uring 读文件

先上一个最小可用的例子，异步读取一个文件并打印。注释里标出每一步在做什么：

#include <liburing.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#define QD 4          // queue depth，队列深度
#define BS 4096       // block size

int main(int argc, char *argv[]) {
    if (argc < 2) { fprintf(stderr, "usage: %s <file>\n", argv[0]); return 1; }

    int fd = open(argv[1], O_RDONLY);
    if (fd < 0) { perror("open"); return 1; }

    struct io_uring ring;
    // 初始化 ring，队列深度 QD；内部完成 setup + mmap + 屏障封装
    if (io_uring_queue_init(QD, &ring, 0) < 0) {
        perror("queue_init"); return 1;
    }

    char *buf = malloc(BS);

    // 1. 拿一个空闲的 SQE
    struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);

    // 2. 把它准备成一次 read 操作（等价于 pread(fd, buf, BS, 0)）
    io_uring_prep_read(sqe, fd, buf, BS, 0);

    // 3. 挂一个 user_data，用来在完成时识别是哪个请求
    io_uring_sqe_set_data(sqe, buf);

    // 4. 提交（一次 io_uring_enter，把 SQ 里所有待提交的 SQE 交给内核）
    io_uring_submit(&ring);

    // 5. 阻塞等待一个完成事件
    struct io_uring_cqe *cqe;
    io_uring_wait_cqe(&ring, &cqe);

    // 6. cqe->res 是本次 I/O 的返回值：>=0 是读到的字节数，<0 是 -errno
    if (cqe->res < 0) {
        fprintf(stderr, "read error: %s\n", strerror(-cqe->res));
    } else {
        char *data = io_uring_cqe_get_data(cqe);
        fwrite(data, 1, cqe->res, stdout);
    }

    // 7. 标记这个 CQE 已被消费（递增 CQ head）
    io_uring_cqe_seen(&ring, cqe);

    free(buf);
    io_uring_queue_exit(&ring);
    close(fd);
    return 0;
}

编译：gcc read.c -o read -luring。

这段代码里最值得记住的三个 API 生命周期：

1. io_uring_get_sqe 从 SQ 里取一个空槽。它可能返回 NULL（队列满了），生产级代码必须判空。
2. user_data 是你和内核之间唯一的「回执凭证」。因为 io_uring 是异步且可乱序完成的，你提交了 read A、read B、write C，它们完成的顺序完全不保证。你只能靠每个 SQE 上挂的 user_data（通常是指向你自己请求上下文结构体的指针）来认领 CQE。
3. cqe->res 的语义：这就是对应同步 syscall 的返回值。成功是字节数/fd/0，失败是负的 errno（-EAGAIN、-EINVAL 等）。永远先判 res < 0。

五、把它变成一个真正的 Echo 服务器：网络 I/O + 事件循环

io_uring 真正的杀手锏在网络。下面是一个单线程 echo 服务器的骨架，展示如何用一个 io_uring 事件循环同时处理 accept / recv / send。为了聚焦主干，省略了部分错误处理：

#include <liburing.h>
#include <netinet/in.h>
#include <string.h>
#include <stdlib.h>

#define MAX_CONN 4096
#define BUF_SIZE 2048

enum { EV_ACCEPT, EV_RECV, EV_SEND };  // 事件类型

// 每个请求的上下文，指针塞进 user_data
struct conn {
    int fd;
    int type;
    char buf[BUF_SIZE];
    int  len;
};

static void add_accept(struct io_uring *ring, int listen_fd) {
    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);
    struct conn *c = calloc(1, sizeof(*c));
    c->type = EV_ACCEPT;
    io_uring_prep_accept(sqe, listen_fd, NULL, NULL, 0);
    io_uring_sqe_set_data(sqe, c);
}

static void add_recv(struct io_uring *ring, struct conn *c) {
    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);
    c->type = EV_RECV;
    io_uring_prep_recv(sqe, c->fd, c->buf, BUF_SIZE, 0);
    io_uring_sqe_set_data(sqe, c);
}

static void add_send(struct io_uring *ring, struct conn *c, int len) {
    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);
    c->type = EV_SEND;
    io_uring_prep_send(sqe, c->fd, c->buf, len, 0);
    io_uring_sqe_set_data(sqe, c);
}

int main() {
    int listen_fd = /* socket() + bind() + listen()，此处省略 */ 0;

    struct io_uring ring;
    io_uring_queue_init(2048, &ring, 0);

    add_accept(&ring, listen_fd);
    io_uring_submit(&ring);

    while (1) {
        struct io_uring_cqe *cqe;
        io_uring_wait_cqe(&ring, &cqe);           // 等待任意完成事件
        struct conn *c = io_uring_cqe_get_data(cqe);
        int res = cqe->res;

        switch (c->type) {
        case EV_ACCEPT:
            // 结果是新连接的 fd；立刻挂一个新的 accept，别让监听饿死
            add_accept(&ring, listen_fd);
            if (res >= 0) {
                struct conn *nc = calloc(1, sizeof(*nc));
                nc->fd = res;
                add_recv(&ring, nc);
            }
            free(c);
            break;

        case EV_RECV:
            if (res <= 0) {          // 0=对端关闭，<0=错误
                close(c->fd); free(c);
            } else {
                add_send(&ring, c, res);   // 收到多少原样发回去
            }
            break;

        case EV_SEND:
            add_recv(&ring, c);      // 发完继续收，形成循环
            break;
        }

        io_uring_cqe_seen(&ring, cqe);
        io_uring_submit(&ring);      // 把本轮新挂的 SQE 一次性提交
    }
}

这个模型和 epoll 事件循环形态上很像，但本质不同：epoll 是「通知你去做 I/O」，io_uring 是「I/O 已经帮你做完了，这是结果」。你不再需要在拿到 readiness 后再调一次 recv()——recv 本身就是异步提交的。这就把每个连接每次读写省下的那次 syscall 全砍掉了。

进阶优化：可以用 io_uring_wait_cqe_nr 或 io_uring_peek_batch_cqe 一次批量收割多个 CQE，用 io_uring_cq_advance(&ring, n) 一次性推进 head，进一步降低单事件开销。

六、进阶特性：把性能榨干的四把武器

6.1 SQPOLL：连提交的 syscall 都省掉

开启 IORING_SETUP_SQPOLL 后，内核会启动一个内核轮询线程，主动扫描你的 SQ。你把 SQE 写进共享内存后，甚至不用调 io_uring_submit（liburing 会智能判断，SQPOLL 下 submit 通常是空操作），内核线程自己就捞走执行了。

struct io_uring_params params;
memset(&params, 0, sizeof(params));
params.flags = IORING_SETUP_SQPOLL;
params.sq_thread_idle = 2000;   // 空闲 2000ms 后内核线程休眠
io_uring_queue_init_params(2048, &ring, &params);

代价：这个内核线程会占一个 CPU 核心空转（在有请求时）。所以 SQPOLL 适合极高吞吐、愿意用一个核换零 syscall 的场景，比如高性能存储引擎、数据库。低负载服务开 SQPOLL 纯属浪费电。注意 sq_thread_idle 控制空闲多久后线程睡眠，睡眠后需要一次 io_uring_enter 把它唤醒。

6.2 注册缓冲区与固定文件：消除每次 I/O 的重复开销

每次 I/O，内核都要对用户传入的 buffer 做 get_user_pages（把用户页锁定到内核），对 fd 做引用计数增减。高频场景下这些「杂税」不可忽视。

• 注册缓冲区（io_uring_register_buffers）：预先把一组固定 buffer 注册给内核，之后用 io_uring_prep_read_fixed / write_fixed，内核跳过 get_user_pages，直接用预映射的页。
• 固定文件（io_uring_register_files）：预先注册一组 fd，之后用「索引」代替真实 fd 提交，跳过每次的 fget/fput 引用计数。配合 IOSQE_FIXED_FILE 标志使用。

在 NVMe 百万 IOPS 的基准里，注册缓冲区 + 固定文件通常能再榨出 5%~15% 的吞吐。

6.3 链式操作（Link）：表达 I/O 之间的依赖

通过 IOSQE_IO_LINK 标志，可以把多个 SQE 串成一条链：只有前一个成功完成，后一个才会执行。经典用例：read 完立刻 write（拷贝），或者 send 请求头后接着 send body，不用等第一个 CQE 回到用户态再提交第二个。

struct io_uring_sqe *sqe1 = io_uring_get_sqe(&ring);
io_uring_prep_read(sqe1, in_fd, buf, len, 0);
sqe1->flags |= IOSQE_IO_LINK;      // 关键：标记为链式

struct io_uring_sqe *sqe2 = io_uring_get_sqe(&ring);
io_uring_prep_write(sqe2, out_fd, buf, len, 0);
// sqe2 不加 LINK，表示链在此结束

io_uring_submit(&ring);   // 一次提交整条链

链中任一环失败，后续会被以 -ECANCELED 取消。这让「零用户态介入」的复合操作成为可能。

6.4 Multishot 与 Provided Buffers：一次提交，多次收割

传统模式下每 accept 一个连接就要重新提交一个 accept SQE。Multishot accept（io_uring_prep_multishot_accept）让你提交一次，之后每来一个连接内核就往 CQ 里塞一个 CQE，不用反复提交。recv 也有 multishot 版本。

配合 Provided Buffers（IORING_REGISTER_PBUF_RING，环形提供缓冲区）——你预先给内核一批 buffer，multishot recv 收到数据时内核自己挑一个可用 buffer 填进去，并在 CQE 的 flags 里通过 IORING_CQE_F_BUFFER 告诉你用了哪个。这解决了 multishot 场景「提交时还不知道该给哪块 buffer」的鸡生蛋问题，是现代 io_uring 高性能网络服务的标配组合。

6.5 零拷贝发送 SEND_ZC（Linux 6.0+）

IORING_OP_SEND_ZC 提供了真正的零拷贝网络发送：数据页直接从用户 buffer DMA 到网卡，跳过内核 socket buffer 的那次拷贝。注意它的完成语义是两段式的：一个 CQE 表示「已提交/结果」，另一个带 IORING_CQE_F_NOTIF 标志的 CQE 表示「网卡真正用完了这块 buffer，你现在可以安全复用/释放它」。用错会导致数据还在发就被你改了。零拷贝对大包（几十 KB 以上）收益明显，小包因为额外的记账开销反而可能变慢。

七、性能到底有多强：一个务实的判断框架

网上各种 benchmark 数字满天飞，但真正该记住的是io_uring 在什么场景赢、赢在哪：

• 高 IOPS 磁盘（NVMe）：这是 io_uring 的诞生初衷。相比同步 pread/pwrite 和老 aio，在 4K 随机读写的百万 IOPS 压力下，io_uring 能显著降低 CPU 占用（syscall 摊薄 + 轮询模式），是目前 Linux 上做存储引擎的首选。
• 高并发短连接网络：multishot accept/recv + provided buffers + 注册文件，能把 epoll 模型里每连接省下的 syscall 累积成可观的 CPU 节省。这也是为什么 Netty、Tokio（Rust）、Nginx（实验性）都在陆续接入。
• 收益有限甚至变慢的场景：低并发、以 CPU 计算为主而非 I/O 密集的服务，io_uring 的复杂度和额外记账开销未必划算；小包 + 零拷贝也可能因记账反而变慢。

一句话：io_uring 是 I/O 密集型、高吞吐场景的利器，不是所有服务的银弹。 如果你的瓶颈根本不在 syscall 数量上，上 io_uring 只会徒增复杂度和风险。

而「风险」这两个字，恰恰引出了这篇文章最戏剧性的部分。

八、性能王者的另一面：为什么 Google 把它全线封禁

2023 年 6 月，Google 安全团队公开发文，宣布在其产品线里大范围禁用 io_uring：ChromeOS 里禁用、Android 里禁用、GKE（Google Kubernetes Engine）的生产环境里默认关闭。理由简洁而扎心——io_uring 是内核里被利用来提权的高发地带。

Google 给出的数据是：在他们 kCTF（内核漏洞悬赏）项目收到的成功利用中，相当大比例（其披露的一批案例里约六成）都用到了 io_uring。这不是危言耸听，而是有几个结构性原因：

8.1 攻击面太大且增长过快

io_uring 是一个「统一异步框架」，意味着它要对接内核里几乎所有子系统：块层、网络栈、文件系统、管道、消息……每接入一个新 opcode，就等于把那个子系统的代码路径也纳入了 io_uring 的攻击面。而且它迭代极快，几乎每个内核版本都在加新特性、新 opcode。新代码 = 新 bug，安全审计的速度跟不上功能扩张的速度。

8.2 异步执行绕过了传统的安全检查

这是最致命的一点。传统 syscall 是在发起进程的上下文里同步执行的，seccomp、SELinux/LSM、audit 这些安全机制都能拦得住、审得到。

但 io_uring 的很多操作是由内核工作线程（io-wq）异步代劳的——操作真正执行时，已经不在原进程的 syscall 上下文里了。历史上这导致：

• seccomp 过滤器失效：你辛辛苦苦用 seccomp 禁掉了某个进程调用 openat，但它可以通过 io_uring 提交一个 IORING_OP_OPENAT，绕过 seccomp 的过滤——因为 seccomp 拦的是 syscall 入口，而 io_uring 是「一个 syscall 提交、内核线程干活」，被禁的那个 syscall 根本没被直接调用。
• 审计/LSM 盲区：早期 io_uring 缺乏细粒度的 LSM 钩子，安全策略难以覆盖它异步执行的操作。

这意味着 io_uring 不仅自身有 bug，还能被当成绕过既有沙箱和安全策略的万能梯子。对 Chrome 这种把「进程沙箱」当命根子的产品来说，这是不可接受的。

8.3 UAF / 竞态是重灾区

异步 + 共享内存 + 复杂生命周期管理，天然是 use-after-free、double-free、竞态条件的温床。SQE/CQE 的引用、注册资源的释放时机、链式操作的取消路径……每一个都可能在并发下踩出内存安全漏洞。CVE 列表里 io_uring 相关的 UAF 一抓一大把。

九、内核社区的反击：安全加固与「可关闭」开关

Google 的封禁不是终点，而是逼着社区加固。这几年 io_uring 的安全机制明显补齐：

9.1 IORING_REGISTER_RESTRICTIONS：自我设限

应用可以在初始化时主动限制自己的 io_uring 实例能用哪些 opcode、哪些标志。比如一个只需要网络收发的服务，可以显式禁掉所有文件系统类 opcode，把攻击面自己收窄。这是「最小权限原则」在 io_uring 里的落地。

9.2 kernel.io_uring_disabled：系统级总开关（Linux 6.6+）

从 Linux 6.6 起，新增了 sysctl kernel.io_uring_disabled，三档：

• 0：所有进程都能用（默认）。
• 1：只有具备 CAP_SYS_ADMIN 的进程能创建 io_uring，普通进程被拒。
• 2：全系统彻底禁用，任何 io_uring_setup 都返回 -EPERM。

# 查看当前状态
sysctl kernel.io_uring_disabled
# 临时彻底禁用
sudo sysctl -w kernel.io_uring_disabled=2
# 永久（写进 /etc/sysctl.d/）
echo 'kernel.io_uring_disabled=2' | sudo tee /etc/sysctl.d/99-io_uring.conf

这给了运维一个干净的「一键关停」手段——不需要重编内核，一条命令就能在整个集群里关掉这个攻击面。很多对安全敏感的发行版和云厂商现在默认走 1 或 2。

9.3 LSM 钩子与 seccomp 补强

社区陆续给 io_uring 加了 LSM 钩子（如 io_uring_override_creds、io_uring_sqpoll 相关的安全检查），让 SELinux/AppArmor 能对 io_uring 的操作施加策略。seccomp 的绕过问题也在通过对 io_uring 提交本身进行过滤等方式缓解。方向是明确的：把 io_uring 拉回到既有安全框架的管辖之下。

十、生产环境的务实决策清单

聊了这么多，落到实处，如果你正在考虑要不要上 io_uring，这份清单可以帮你做决定：

1. 先确认瓶颈真的在 syscall / I/O 路径上。用 perf 看 CPU 火焰图，如果 syscall 开销占比很低，别折腾。
2. 无脑用 liburing，别裸调三个 syscall，屏障和 ring 管理坑太深。
3. 网络高并发：优先考虑 multishot accept/recv + provided buffers + 固定文件的组合。
4. 存储/数据库：优先考虑 SQPOLL + 注册缓冲区，接受用一个核换零 syscall。
5. 安全敏感环境（多租户、跑不可信代码、面向公网的沙箱）：认真评估攻击面。要么用 IORING_REGISTER_RESTRICTIONS 自我收窄，要么干脆用 kernel.io_uring_disabled 关掉。不要在能跑第三方不可信代码的机器上无限制开放 io_uring。
6. 保持内核新版本：io_uring 的 bug 修复和安全加固几乎每个版本都在推进，老内核（尤其 5.x 早期）的 io_uring 漏洞多且缺乏 sysctl 开关，风险显著更高。
7. 务必判 NULL 和负 res：io_uring_get_sqe 会返回 NULL，cqe->res 会是负 errno，这两个是新手最常翻车的地方。

十一、总结与展望

io_uring 是过去十年 Linux I/O 领域最重要的一次范式跃迁。它用「共享内存环形队列 + 批处理 + 真异步」的组合，第一次让磁盘和网络 I/O 都能以接近零 syscall 的成本运转，把高性能服务端的天花板又抬高了一大截。Tokio、Netty、各类现代存储引擎的接入，证明了它的价值不是纸上谈兵。

但它同时也是一个绝佳的工程隐喻：极致的性能，往往是用极致的复杂度和攻击面换来的。 统一异步框架的强大，恰恰源于它触达了内核的每一个角落；而触达每个角落，也意味着把每个角落的风险都收进了自己怀里。Google 的封禁不是否定 io_uring，而是提醒所有人：一项技术的「能力边界」和「安全边界」必须被同时认真对待。

展望未来，io_uring 的走向大概率是「能力继续扩张 + 安全持续收口」双线并行：一边是零拷贝、multishot、更多 opcode 把性能推向新高；一边是 LSM/seccomp 集成、restrictions、sysctl 开关把它关进可控的笼子。对我们工程师而言，真正的功力不在于「会不会用 io_uring」，而在于能不能在性能诱惑和安全代价之间，为自己的具体场景做出清醒的取舍。

毕竟，最快的那条路，未必是你该走的路。想清楚自己的瓶颈和威胁模型，再决定要不要请出这位「性能王者」——这才是一个成熟工程师该有的姿态。