1. 日志系统概述：为什么需要日志追踪？

做协议栈开发，说白了就是跟一堆看不见摸不着的状态机、定时器、消息队列打交道。你写了几万行 C 代码，编译通过了，烧进去跑了，结果设备连不上网——这时候你怎么办？

我刚开始做 4G NAS 层的时候，就遇到过这种尴尬。代码逻辑看了三遍，觉得没问题。单步调试？协议栈跑在实时系统上，单步一停，对端早就超时重传了。打印加多了，时序又变了。那段时间我真是焦头烂额。

后来一位老前辈跟我说了一句话，我记到现在：“没有日志，协议栈就是黑盒；有了日志，你才有一双眼睛。”

1.1 协议栈开发的核心痛点

为什么协议栈开发这么依赖日志？你想想看，它有几个天然的特点：

• 实时性要求高：毫秒级的定时器，几十微秒的中断响应。你没法像应用层那样随意打断。
• 状态机复杂：一个 RRC 连接管理，少说十几个状态，状态迁移条件几十条。出问题了你得知道“当前在哪个状态，收到了什么消息，为什么没跳转”。
• 多模块交互：NAS 层跟 RRC 层交互，RRC 层跟 PDCP 层交互，PDCP 又跟 RLC、MAC 层交互。问题往往不在你盯的那个模块里，而在接口处。
• 环境依赖强：同样的代码，在实验室能跑，到了外场就出问题。射频环境、干扰、移动速度，这些你都没法在 IDE 里模拟。

1.2 日志在协议栈中的三大核心价值

我个人习惯把日志的价值归纳为三点。这三点在我做过的 4G、5G、蓝牙协议栈项目里，从来没变过。

价值维度	具体说明	我遇到过的例子
问题复现与定位	记录现场的关键信息，让 Bug 可追溯	外场测试偶现附着失败，靠日志回放定位到 TAU 定时器溢出
时序分析	还原消息交互的时间线，检查谁先谁后	PDCP 重排序窗口滑动异常，日志显示下层乱序到达超了窗口边界
状态机验证	确认状态迁移是否符合协议规范	RRC 重建流程卡在中间态，日志发现收到了非法的重配置消息

1.3 日志追踪 vs 传统调试手段

有人可能会问：我用 JTAG 单步调试不行吗？用断点不行吗？嗯，这里要注意，协议栈开发和普通嵌入式开发有个本质区别——它是个分布式实时系统。

我列个对比表，你看完就明白了：

调试手段	适用场景	局限性
JTAG / 断点	单模块、单线程的初始化流程	打断实时流程，改变时序；多核/多线程无法同步
逻辑分析仪	硬件接口信号分析	只能看物理层信号，看不到协议栈内部状态
printf / 串口打印	简单信息输出	无分级、无时间戳、无法过滤，信息爆炸时反而干扰
日志追踪系统	全流程、多模块、长时间运行	需要前期设计投入，但后期排查效率提升数倍

1.4 一个真实的教训

我曾经接手过一个蓝牙协议栈的项目。前任工程师几乎没加日志，整个代码里就几个 printf。有一次设备配对总是超时，我花了整整两周去排查。

没有日志，我只能靠猜。猜是 L2CAP 层的问题？加几行打印，编译烧录，跑一次，不行。再猜是 SMP 层的问题？再加打印，再跑。一次实验周期 10 分钟，两周下来我烧了上百次固件。

后来我实在受不了，花了两天时间把日志系统搭起来。加上模块 ID、时间戳、分级过滤。再跑那个配对超时的场景，日志一抓，5 分钟就定位到了——是 ATT 层的 MTU 协商顺序反了。

从那以后，我经手的每个项目，第一件事就是搭日志框架。这个习惯，我一直保持到现在。

1.5 本章知识体系

下面这张图，是我对日志追踪在协议栈中定位的理解。它不是一个独立工具，而是贯穿开发、测试、外场、维护全流程的“基础设施”。

1.6 什么样的日志才算“好日志”？

说了这么多，那到底什么样的日志系统才是我们协议栈开发需要的？我总结了几条标准：

1. 有分级：ERROR、WARN、INFO、DEBUG、TRACE。别所有信息都用一个级别打，否则关键信息会被淹没。
2. 有时间戳：至少精确到毫秒。做时序分析时，时间戳就是你的“证据链”。
3. 有模块标识：一眼能看出这条日志是 NAS 层打的，还是 RRC 层打的，还是 PDCP 层打的。
4. 可过滤：能按级别、按模块、按关键字过滤。信息太多等于没有信息。
5. 低开销：日志本身不能影响系统实时性。我见过有人在高频中断里打日志，直接把系统拖死——这是反面教材。