简介：Goahead 3.6.2 源码包面向嵌入式与物联网方向的开发者，以及需要在资源受限设备上集成轻量级 Web 服务的工程人员，核心解决 HTTP/HTTPS 服务搭建、SSL/TLS 加密通信与二次开发问题。压缩包共 530 个文件、约 4.53MB，包含 30 个 C 源文件与 18 个头文件、138 个 HTML 页面及配套 CSS/JS 资源，并带有 vcxproj、sln、mk、configure 等跨平台构建脚本，以及 key、crt 证书样例和 md、txt 说明文档，覆盖源码、示例站点、编译配置与安全素材。已有 256 人学习，适合按目录梳理服务器事件驱动模型、动态内容生成和 HTTPS 握手配置。读者可据此完成源码编译、嵌入式移植、证书替换与接口调试，并借助示例页面和构建工程快速验证功能，减少从零摸索环境搭建与加密接入的成本。

1. 一个几兆的 C 源码包，凭什么替掉设备上的 Nginx

goahead-3.6.2.tar.gz 解压完只有几兆，却是一个自带 HTTP/1.1、WebSocket、JST 模板、摘要认证和上传处理的开源 Web 服务器，全部用 C 写。我第一次把它塞进一台 64MB 内存的边缘网关时，对比就很明显：另一套方案要连二进制、配置文件、扩展模块一起搬，而 goahead 编出来就是一个几百 KB 的可执行文件加一个文档目录。它解决的问题不是「扛住公网大流量」，而是「设备自己带一个管理面」——和业务 C 代码同进程运行，不用额外起解释器，静态页和动态接口走同一套路由。做嵌入式网关、工控面板、单板管理页的人用得上；想拿它当公网反向代理的，方向就不对。

2. 解包与首次构建：从 tar.gz 到能 curl 通的最小可运行体

拿到源码包之后最容易犯的错，是直接make && ./goahead然后对着 404 或端口占用发呆。这个包不是那种./configure一路到底的项目，它把平台差异收进了projects/下的一组 mk 文件，把功能裁剪收进了src/me.h。先把这两处认清楚，后面的编译和裁剪才不至于每次推倒重来。

2.1 解包后先看三张地图：src、projects、test

解压后顶层就几个目录，但每个目录的职责差别很大，改错地方会让下一次同步上游版本时非常难受。

# 解包并看顶层结构 tar -xzf goahead-3.6.2.tar.gz cd goahead-3.6.2 ls -1 # Makefile # projects/ # src/ # test/ # doc/

src/是全部实现：goahead.c管生命周期，http.c管协议解析，handler.c管路由分发，file.c管静态文件，action.c管 GoAction，jst.c管 .asp 模板，auth.c管认证，upload.c管上传，另外还有socket.c、ssl.c、options.c这些基础设施。真正对外暴露的接口全在src/goahead.h里，功能开关和各类上限则集中在src/me.h。

projects/下是一堆goahead-*.mk，命名规则大致是「系统-架构-变体」，默认构建走的就是其中一个。test/是官方给的文档根示例，里面有静态页、.asp模板和测试用脚本，第一次启动时把它当--documents指向的目录最省事。doc/里是 API 和配置说明，遇到函数签名不确定时优先翻它，比在网上搜二手代码靠谱。

# 先确认三个关键文件的规模，心里有个数 wc -l src/me.h src/goahead.h src/main.c # 看默认 mk 是怎么被顶层 Makefile 选中的 grep -n "projects/" Makefile | head -20

这几条命令的意义在于：me.h通常只有几百行，是裁剪的主战场；goahead.h是全部 PUBLIC 函数的声明集合，写代码时对着它抄函数名，比凭记忆写强得多；Makefile里能看到默认 mk 的选择逻辑，后面交叉编译要复制哪一份、改哪几个变量，全靠这一步。

提示：不要一上来就改src/*.c。绝大多数需求（换端口、关功能、改上限、加认证）都能在me.h、main.c和 mk 文件里解决，改内核源码会让后续升级变成人工 diff。

2.2 用默认 mk 编出宿主机的可执行文件

宿主机上先编一版跑通，是后面交叉编译的对照组。这一步不需要任何额外依赖，默认配置不启用 SSL，所以不用先装 OpenSSL 开发包。

# 默认构建，输出会打印实际使用的 mk 文件和编译选项 make # 产物位置 ls -l build/linux-x64-default/bin/goahead # 想重新来一遍 make clean && make

构建产物落在build/<系统>-<架构>-<变体>/bin/下，这个路径值得记一下，因为它同时决定了中间.o文件的位置，排查「为什么我的宏没生效」时，去这个目录看编译命令行比猜快得多。

# 看某个源文件到底带了哪些 -D 宏 grep -rn "me.h" build/linux-x64-default/ 2>/dev/null | head # 或者直接看 make 打印出来的编译行 make clean && make 2>&1 | grep -m3 "gcc"

gcc 那一行里会带一串-DME_GOAHEAD_*，这就是me.h里开关最终生效的形态。如果你的修改没起作用，八成是改错了 mk 文件，或者构建目录里残留了旧的.o，make clean之后再编一次就能确认。

构建时长在普通开发机上通常十几秒到几十秒，和源码规模匹配。如果卡在某个文件反复报错，先看是不是工具链版本太老——这套代码用的是比较保守的 C 写法，但个别地方仍要求 C99 及以上。

2.3 三段式启动代码：websOpen、websListen、websServiceEvents

编出来的goahead本身就能跑，命令行参数覆盖了大部分调试场景。先用它验证环境，再把同样的流程搬进自己的进程。

# 用官方 test 目录当文档根，监听本地 8080，开详细日志 ./build/linux-x64-default/bin/goahead \ --home . \ --documents ./test \ --listen 127.0.0.1:8080 \ -v # 另开一个终端验证 curl -i http://127.0.0.1:8080/index.html

--home指向放路由表和认证文件的目录，--documents是静态资源和模板的根，--listen支持ip:port形式，-v打开请求级日志。第一次跑建议就用这三个参数，不要自己拼配置文件，先把「能返回一个页面」这件事确认下来。

要把服务器嵌进自己的业务进程，入口就是三个调用：打开、监听、事件循环。

/* 最小启动骨架，对应 src/main.c 的主流程 */ #include "goahead.h" static void statusAction(Webs *wp) { /* 从查询串或表单取参数，第三个实参是缺省值 */ cchar *fmt = websGetVar(wp, "format", "text"); websSetStatus(wp, 200); websSetContentType(wp, "application/json"); websWrite(wp, "{\"uptime\":%d,\"fmt\":\"%s\"}", 42, fmt); /* action 返回后由框架收尾，这里不要手动 websDone */ } int main(int argc, char **argv) { int finished = 0; /* 参数一 home：路由表/认证文件所在目录；参数二：文档根 */ if (websOpen(".", "./test") < 0) { return 1; } /* 注册后 URL 映射为 /action/status */ websDefineAction("status", statusAction); if (websListen("0.0.0.0:8080") < 0) { websClose(); return 1; } /* 阻塞式事件循环，finished 置 1 时退出 */ websServiceEvents(&finished); websClose(); return 0; }

这段代码里三个调用的顺序不能换：websOpen负责初始化内存池、符号表和路由表，websListen才创建监听套接字，websServiceEvents进入 select/poll 循环。websDefineAction必须放在websOpen之后、监听之前，原因是 action 表在 open 阶段建立。

websServiceEvents的参数是一个退出标志指针，传 NULL 在部分小版本上会被解引用，稳妥写法就是像上面那样给一个真实变量，另起一个线程或信号处理把它置 1。websGetVar的返回指针指向请求内部缓冲区，只在当前 action 调用期内有效，想留到异步回调里用必须自己拷贝——这条在后面会反复出现，因为它是内存类问题的头号来源。

3. 路由与请求处理：Handler、Action、JST 三层怎么选

请求进来之后走哪条路，是这个项目里最影响后期维护的设计决定。goahead 给了三套机制：自定义 handler 接管整条 URI，GoAction 走/action/前缀做轻量接口，JST 把.asp模板翻译成 C 函数。三者不是替代关系，选错了照样能跑，但会在并发、内存和调试成本上慢慢显形。

3.1 Handler 与 Action 的分界线：什么时候不该用 CGI

自定义 handler 的定位是「替换某一类 URI 的处理逻辑」。注册一个 handler 并绑定到某个路由后，凡是命中该路由的请求都不再走文件服务，而是直接进你的函数，由你决定读什么、写什么、什么时候结束。它适合做协议转换、鉴权前置、特殊格式输出这类需要完全掌控响应过程的场景。

GoAction 则是上层的语法糖：注册一个名字，框架自动把它挂到/action/<name>下，你只管在函数里读参数、写响应。它的约束更少，犯错空间也更小。

CGI 是第三种，走子进程模型：每个请求 fork 一次，环境变量传参，标准输出就是响应体。它胜在语言无关，任何能读环境变量、能往 stdout 写的程序都能挂上去；代价是进程创建开销和参数传递的边界问题。设备上并发一高，CGI 往往最先成为瓶颈。

选型上我的习惯是：能用 Action 解决的绝不写 Handler，能用 Handler 解决的绝不上 CGI。只有当已经有一个现成的可执行程序、且短期内不打算重写时，才把 CGI 打开。

3.2 GoAction 实战：注册 /action/status 并读参数

先看一个能直接抄的接口，它同时覆盖了参数读取、内容类型设置、错误返回和日志。

/* 设备状态查询接口，注册名 status 对应 URL /action/status */ static void statusAction(Webs *wp) { cchar *dev = websGetVar(wp, "dev", NULL); cchar *raw = websGetVar(wp, "raw", "0"); /* 必填参数缺失时走统一错误出口 */ if (dev == NULL || *dev == '\0') { websError(wp, 400, "missing dev"); return; } /* 设备名只允许字母数字和短横线，挡住拼接类注入 */ for (cchar *p = dev; *p; p++) { if (!isalnum((unsigned char)*p) && *p != '-') { websError(wp, 400, "bad dev"); return; } } websSetStatus(wp, 200); websSetContentType(wp, "application/json"); if (strcmp(raw, "1") == 0) { /* 大响应：先写长度再写体，避免分块编码在老旧客户端上出问题 */ websWrite(wp, "{\"dev\":\"%s\",\"raw\":[1,2,3,4]}", dev); } else { websWrite(wp, "{\"dev\":\"%s\",\"ok\":true}", dev); } }

代码里几处值得说明。websGetVar第三个参数是缺省值，传 NULL 表示「没有就返回 NULL」，传字符串则会返回这个缺省串，用它区分「参数没传」和「参数传了空」很方便。websError会一次性把状态码、响应头和错误体写完并结束请求，调用之后不要再写任何内容。websSetContentType必须在第一次websWrite之前调用，否则响应头已经发出去了，设置不会生效。

那段字符校验看着土，但在设备管理面上非常必要。设备名往往会被拼进日志、拼进文件路径、拼进下游命令，不校验就等于把一个可控字符串直接交给下游。用isalnum加白名单的方式比黑名单过滤稳，因为它默认拒绝。

注册和访问：

# 编译后启动，然后访问 curl -i "http://127.0.0.1:8080/action/status?dev=node-1" curl -i "http://127.0.0.1:8080/action/status?dev=node-1&raw=1" curl -i "http://127.0.0.1:8080/action/status"

第三条应该返回 400 和missing dev。如果它返回 200 或者 404，说明 action 没注册成功：404 是名字对不上，200 是校验分支没走到。日志里开-v能看到请求命中的路由和最终状态码，比在代码里到处加打印快。

注意：websGetVar返回的指针指向请求缓冲区，生命周期到本次 action 返回为止。需要异步处理时，用strdup拷一份并在回调里释放，不要把裸指针塞进队列。

3.3 JST 模板：.asp 在编译期变成 C 函数

JST 是这套代码里最容易低估的部分。.asp文件里，<% %>之外的内容原样作为输出，<% %>之内是标准 C 片段，可以直接调用websWrite、websGetVar这些接口，变量wp在片段里天然可用。模板最终会被翻译成 C 函数，所以语法错误在构建或首次访问时就会暴露，而不是等到运行时才渲染出半截页面。

<!-- test/status.asp --> <html> <body> <h2>节点状态</h2> <% cchar *dev = websGetVar(wp, "dev", "unknown"); cchar *mode = websGetVar(wp, "mode", "normal"); websWrite(wp, "<p>device: %s</p>", dev); websWrite(wp, "<p>mode: %s</p>", mode); if (strcmp(mode, "debug") == 0) { websWrite(wp, "<p class=\"warn\">调试模式已开启</p>"); } %> </body> </html>

访问/status.asp?dev=node-1&mode=debug就能看到分支生效。几个约定要记住：模板里不要写#include，头文件在编译模板时统一带；不要把%>拆到多行字符串里；<%和%>之间必须能构成完整语句，写半条if跨块会直接编译失败。

输出转义是这套机制最需要自己补的一环。websWrite(wp, "%s", dev)不会做 HTML 转义，如果dev来自用户输入并且要回显到页面，就必须自己过一遍：把&、<、>、"换成实体。设备管理面通常还有管理员登录，一个存储型 XSS 足以把会话 cookie 拿光。我的做法是在websWrite之外再封一层htmlWrite，凡是回显用户数据一律走它，模板里禁止直接输出外部字符串。

模板的另一个坑是调试信息。JST 报错时给的是生成后的 C 行号，和.asp行号对不上。定位办法是打开构建日志，找到生成的那份中间.c文件，对照着看，通常两三次就能建立映射感。

4. 把功能开关做进 me.h：裁剪体积与打开认证/上传

默认构建把所有功能都编进去，宿主机上无所谓，到了 Flash 只有几 MB 的板子上就得算账。裁剪入口只有一个：src/me.h。这里集中定义了各模块开关、缓冲区大小、超时时间、并发上限，改完之后重新编译，体积和内存占用会立刻反映出来。

4.1 功能宏与体积/内存的取舍表

me.h里的宏都以ME_GOAHEAD_开头，命名基本自解释。下面这张表是我在几个模拟项目里反复用到的组合，宏名以你手上src/me.h的实际定义为准，改之前用grep -n "ME_GOAHEAD_" src/me.h过一遍，确认拼写和默认值。

/* src/me.h 节选，按项目裁剪 */ #define ME_GOAHEAD_CGI 0 /* 不挂外部程序，省掉 fork 路径 */ #define ME_GOAHEAD_JST 1 /* 保留模板渲染 */ #define ME_GOAHEAD_DIGEST 1 /* 摘要认证，密码不裸传 */ #define ME_GOAHEAD_UPLOAD 1 /* 固件升级要用 */ #define ME_GOAHEAD_SSL 0 /* 内网部署，先不开 */ #define ME_GOAHEAD_ACCESS_LOG 1

裁剪的收益不只是体积。关掉 CGI 之后，那条 fork/exec 的代码路径整个不参与编译，攻击面也跟着小了。关掉 SSL 则要清楚代价：同一网段内抓包就能看到凭据，只能用在隔离网络里。

改完必须重新全量编译，并且确认宏真的生效：

make clean && make 2>&1 | grep -m2 "ME_GOAHEAD_CGI" # 对比裁剪前后的可执行文件大小 ls -l build/linux-x64-default/bin/goahead

如果体积没变化，先怀疑构建目录没清干净，再怀疑改的不是实际被 include 的那份me.h——有些 mk 会通过-I指定额外的头文件搜索路径，顺序不对就会命中另一份。

4.2 开启 Digest 认证与角色控制

认证这件事在设备管理面上是硬要求。基础认证把用户名密码做一次 base64 就发出去，等同明文；摘要认证传的是挑战响应，密码不出网。开启方式分两步：打开宏，准备认证文件。

# auth.txt，每行 用户名:域:密码 admin:devicerealm:Adm1n-Pass operator:devicerealm:0perator-Pass guest:devicerealm:guest-Pass

域（realm）必须和代码里设置的一致，否则客户端算出的摘要对不上，表现为「密码明明是对的，就是 401」。

/* 启动时设置认证域，必须与 auth.txt 第二列一致 */ websSetRealm("devicerealm"); /* 指定认证文件，路径相对 home 目录 */ websSetAuthFile("auth.txt");

websSetRealm要在websListen之前调用。认证文件里的密码可以是明文，框架在比对时会自己算摘要；生产环境更稳的做法是预先生成密文写进去，这样即使文件泄露，密码本身也不暴露。

权限分级靠路由配置完成：把管理接口挂在需要认证的路由上，把只读页面挂在公开路由上。这里的关键是「默认拒绝」——先给整个/action/前缀加认证，再对个别只读接口单独放开，而不是反过来。反过来写的话，新加一个接口忘了配，它天然就是公开的。

注意：401 响应里不要回显「用户名不存在」或「密码错误」这类区分信息，统一成一句认证失败，避免被用来枚举账号。

4.3 上传限制与超时参数：三个不设就会翻车的值

上传和长连接是最容易在上线后暴露问题的两块，因为它们的行为依赖客户端，测试阶段很难覆盖全。三个值必须在me.h里显式设定，不能吃默认。

第一个是上传体积上限。默认值往往偏大，一块 Flash 装不下那么大的临时文件，写满之后表现为上传卡死或者设备重启。设定时按「固件包大小 × 1.2」留余量，不要按最大值给。

第二个是请求体上限。非上传接口的 POST 体通常很小，给一个几百 KB 的硬上限，超过直接 413，能挡掉一批畸形请求和误配置的客户端。

第三个是空闲超时。keep-alive 连接如果一直不关，连接槽位会被慢慢占满，表现为「跑几天之后新连接进不来，重启就好」。设一个几十秒的空闲回收时间，比调大最大连接数有效得多。

/* 上限类宏，单位按 me.h 注释，通常是字节或秒 */ #define ME_GOAHEAD_LIMIT_UPLOAD (4 * 1024 * 1024) /* 固件包上限 */ #define ME_GOAHEAD_LIMIT_POST (256 * 1024) /* 普通 POST 体 */ #define ME_GOAHEAD_LIMIT_TIMEOUT 30 /* 空闲连接回收，秒 */ #define ME_GOAHEAD_LIMIT_MAX_CLIENTS 64 /* 并发连接上限 */

这几个值之间是有关联的：最大连接数乘以单连接缓冲区大小，就是最坏情况下的内存占用，得落在板子能承受的范围内。64 个连接、每个几 KB 缓冲，加起来几百 KB，对 64MB 内存的设备是安全的；把连接数拉到 512 而不同步算内存，就会出现「压测时随机崩、日志里什么都没有」这种最难查的故障。

websGetUpload读取上传内容时要注意，返回的缓冲区由框架管理，处理完不需要手动释放，但要自己校验长度和内容类型。固件升级这类场景还应该加一道校验和比对，传完之后先算摘要再决定是否写入分区，避免半个包刷进去导致设备变砖。

5. 交叉编译与运行排查：五条血泪踩坑记录

宿主机跑通只是热身，真正花时间的是把它挪到目标板上。这一步出问题的地方高度集中：工具链选错、mk 文件改错、运行时路径不对、库依赖缺失、以及最隐蔽的——编出来的二进制在板上能跑但行为诡异。

5.1 复制一份平台 mk：CC、CFLAGS、LDFLAGS 怎么改

不要直接改projects/下原有的 mk 文件，复制一份改成自己的名字，然后指定用它构建。这样升级源码时只需要把新文件再对一遍，不用做三方合并。

# projects/goahead-linux-armv7.mk 关键片段 # 工具链前缀按实际交叉编译器改 CC = arm-linux-gnueabihf-gcc AR = arm-linux-gnueabihf-ar RANLIB = arm-linux-gnueabihf-ranlib STRIP = arm-linux-gnueabihf-strip # 目标板是 ARMv7 硬浮点，按实际 CPU 调整 CFLAGS += -march=armv7-a -mfpu=vfpv3 -mfloat-abi=hard CFLAGS += -Os -ffunction-sections -fdata-sections LDFLAGS += -Wl,--gc-sections -Wl,-s

-Os优化体积而不是速度，设备管理面不是计算密集型，体积更值钱。-ffunction-sections配--gc-sections能把没引用到的函数整个丢掉，配合上一章的宏裁剪，效果叠加明显。-Wl,-s去掉符号表，进一步压缩，但要在发布版才用——调试版留着符号，否则板上出问题时连函数名都看不到。

# 用自定义 mk 构建，输出目录会带自己的变体名 make ME_GOAHEAD_MK=projects/goahead-linux-armv7.mk # 确认产物的目标架构 file build/linux-armv7-*/bin/goahead # 看动态库依赖，交叉环境最容易在这里翻车 arm-linux-gnueabihf-readelf -d build/linux-armv7-*/bin/goahead | grep NEEDED

file输出里出现ARM、EABI5、hard-float才算对。readelf -d列出来的NEEDED项就是板上必须存在的库，如果板子的根文件系统和工具链不是同一套，最常见的结果是「一执行就报找不到 libc.so.6 的某个版本」。

5.2 踩坑记录：现象 → 原因 → 解决

第一条：板上执行直接Illegal instruction。现象是二进制拷过去，一跑就死，dmesg里能看到非法指令。原因通常是编译选项和目标 CPU 不匹配——比如工具链默认按 ARMv7-A 加 NEON 编，而板子实际是不带 NEON 的 ARMv6，或者浮点 ABI 一边 hard 一边 soft。解决方式是把-march、-mfpu、-mfloat-abi三个值对着板子的/proc/cpuinfo和工具链默认值逐项核对，宁可保守一点，用 ARMv5 的通用选项先跑通，再逐步加优化。

第二条：能启动，但一访问就报 404，静态页也找不到。现象是日志里能看到请求进来，路径却拼成了奇怪的样子。原因是--home和--documents用的是相对路径，而启动脚本的工作目录和你以为的不一样。解决方式是启动前cd到固定目录，或者在代码里用getcwd拼出绝对路径再传给websOpen。这一点在 systemd 或自研启动器下尤其容易踩，因为工作目录默认是/。

第三条：上传小文件正常，一传固件就断连。现象是进度走到某个百分比连接被重置，日志里没有明显报错。原因是上传体积上限没有调整，或者临时目录所在分区空间不足，写到一半失败。先确认ME_GOAHEAD_LIMIT_UPLOAD的值，再确认/tmp或指定目录的剩余空间，两者都排除之后再去看是不是看门狗在长请求期间触发了复位。

第四条：压测时随机崩溃，日志空白。现象是几十个并发跑一段时间后进程消失，没有 core，也没有错误日志。原因是单连接缓冲区乘以连接数超过了实际可用内存，触发 OOM 被内核杀掉，而日志还没来得及刷盘。解决方式是同时下调ME_GOAHEAD_LIMIT_MAX_CLIENTS和缓冲区大小，并且把访问日志改成带缓冲刷盘之外再加一个周期性fflush。这条我踩过两次，第二次才发现是日志本身把最后一点内存吃掉了。

第五条：认证在浏览器上正常，用脚本调用一直 401。现象是同样的账号密码，浏览器能进，curl 或自研客户端不行。原因是摘要认证要求客户端先收 401 挑战、再带着 nonce 重算摘要，脚本里如果直接带基础认证头，服务端不认。解决方式是用curl --digest -u user:pass验证服务端没问题，再对照客户端实现检查 nonce 计数和qop字段。另外认证域拼写不一致也会表现成完全一样的症状，先看服务端配置。

5.3 板上自检顺序：先网络、再文件、后逻辑

到了板上不要一上来就点页面，按固定顺序过一遍，能把问题范围快速压小。

# 1. 进程在不在、监听端口对不对 ps | grep goahead netstat -lntp 2>/dev/null | grep 8080 # 2. 本机回环能不能通，排除网卡和防火墙 wget -qO- http://127.0.0.1:8080/index.html | head -5 # 3. 静态文件路径对不对 ls -l /opt/app/test/index.html # 4. 动态接口能不能进 action wget -qO- "http://127.0.0.1:8080/action/status?dev=node-1"

这四步分别对应「进程活着」「端口在听」「文档根正确」「action 注册成功」四个层次。任何一步失败，就往对应方向查，不用看别的。回环能通但局域网不通，问题在网卡配置或监听地址绑到了127.0.0.1；静态页能出但接口 404，问题在 action 注册或路由表；两者都 404，问题在--documents。

再补一条经验：板上调试优先用串口日志，不要依赖网络回传。设备一旦网络出问题，正好是最需要看日志的时候，而日志恰恰传不出来。

6. 上线前把这三件事做完，能省掉一轮返工

第一件是压测，但不是压 QPS，而是压「连接数 × 保持时间」。用几十个并发连接挂着不发请求，观察内存曲线的斜率，如果十分钟内持续上涨，说明连接回收没生效，回去检查空闲超时。第二件是把日志级别和日志量算清楚，请求级日志在调试期很有用，上线后如果每个请求写一行且不轮转，几天就能把分区写满，所以必须配一个按大小切分的策略。

第三件是留一个不依赖页面的健康检查接口，直接返回进程自身的运行状态，不要查数据库、不要读文件。它在设备「页面打不开但进程还在」的时候特别有用，能立刻区分是业务逻辑卡死还是网络层断了。

最后给一个我自己的习惯：每次交叉编译出新版本，先在一台同架构的开发板上跑一遍上面那四步自检，再连压测脚本跑十分钟，两条都过了才往现场推。有一次图快跳过了压测，结果设备在现场跑到第三天连接槽位耗尽，被迫远程重启，之后再没省过这一步。希望帮到你。

本文还有配套的精品资源，点击获取