把技术问题，
写成可以复用的经验。

先定义每个任务的一次工作量

轮询式结构的关键不是把几个无限循环放到一起，而是让每个任务每次只执行有限的一步。处理完当前步骤后立即返回主循环，下一轮继续推进。

for (;;) {
    input_poll();
    protocol_poll();
    device_poll();
    timer_poll();
    wait_for_event_or_timeout();
}

用状态保存进度

需要等待数据、超时或硬件完成的任务，可以用状态机保存进度。尚未满足条件时返回，不在任务内部反复等待。超时判断应使用单调时钟，避免系统时间调整造成误判。

注意阻塞和任务公平性

文件读写、网络连接和设备访问都可能阻塞。应结合非阻塞接口、事件通知或有限超时处理。队列数据很多时，每轮限制处理数量，避免单个任务占满主循环。日志与界面可按实际需求独立组织。

这种结构适合任务数量有限、步骤可拆分的程序；计算耗时很长的工作需要另外安排，不能靠轮询自动解决。

显式组合字节

协议中的大端整数将高位字节放在前面。解析时可以用移位和按位或组合，避免把接收缓冲区直接转换为结构体指针。

#include <stdint.h>
#include <stddef.h>
#include <stdbool.h>

static bool read_be16(const uint8_t *buf, size_t len,
                      uint16_t *value)
{
    if (!buf || !value || len < 2) return false;
    *value = ((uint16_t)buf[0] << 8) | buf[1];
    return true;
}

使用示例

uint8_t data[] = {0x12, 0x34};
uint16_t value;
if (read_be16(data, sizeof data, &value)) {
    /* value == 0x1234 */
}

解析前先检查边界

读取字段之前先检查剩余长度。处理多字段帧时，逐步推进偏移量，并检查帧头、声明长度和校验值。不要假设 C 位域的排列、结构体填充和 CPU 字节序与通信协议相同。

示例只展示无符号 16 位字段读取，不包含完整帧校验或设备协议定义。

先确认服务是否正常启动

systemctl status nginx --no-pager -l
sudo journalctl -u nginx -b -n 50 --no-pager

第一条查看当前状态和启动命令，第二条查看本次开机的最近日志。把 nginx 替换为实际服务名。修改配置后，不应只凭重启命令没有输出就判断服务运行正常。

再确认监听地址

sudo ss -lntp
curl --noproxy '*' -I http://127.0.0.1/

监听在 127.0.0.1 的服务通常只接受本机连接；监听所有地址也不代表公网一定可达，还要核对云安全组与本机防火墙。

按层定位问题

本机访问失败，先检查进程和配置；本机正常、公网失败，再检查监听地址、DNS、安全组和防火墙。反向代理场景还需要分别验证入口服务和后端服务，避免一次修改多个环节。

先看当前状态

git status
git log --oneline -5
git reflog -10

提交记录描述分支历史；reflog 记录本地引用的近期移动，可帮助找到重置前的位置。它不是长期备份，重要修改应及时提交并备份。

只取回一个文件

git restore --source=提交号 -- path/to/file.c

这条命令从指定提交恢复工作区文件，不切换分支，也不移动当前分支指针。它会覆盖该文件的未提交修改，执行前应先保存需要保留的内容。

恢复前先比较

git diff 提交号 -- path/to/file.c

先确认目标版本和当前文件的差异，再决定恢复文件还是调整分支历史。已经共享的提交历史，应考虑协作影响后再操作。