1. 项目概述：从零构建一个802.15.4星型网络
如果你正在开发一个低功耗的无线传感器网络，比如智能家居的传感器节点、工业数据采集器或者环境监测设备，那么你大概率绕不开IEEE 802.15.4这个标准。它就像是无线物联网世界的“方言”，Zigbee、Thread这些大名鼎鼎的协议栈都建立在它的基础之上。但很多时候，我们直接使用Zigbee SDK，却对底层MAC层如何具体协调设备入网、如何可靠地收发数据一知半解，出了问题只能盲目调试。
最近，我基于Freescale（现NXP）的MC1322x平台，完整实现并深度剖析了一个802.15.4 MAC层的星型网络。这个项目没有依赖任何完整的Zigbee协议栈，而是直接操作MAC层原语，实现了协调器与终端设备从扫描、关联、数据传输到状态维护的全流程。踩过不少坑，也收获了很多在高层协议栈文档里找不到的细节。今天，我就把协调器如何管理设备列表、终端设备如何“敲门”入网、数据包如何通过间接传输确保送达，以及背后的“Purger”或“帧过期”机制是如何充当网络“看门狗”的，掰开揉碎了讲给你听。无论你是想深入理解无线传感网络底层机制，还是正在为自己的产品设计定制化的轻量级网络，这篇内容都能提供可直接复现的参考。
2. 网络核心设计思路与架构拆解
在动手写代码之前，我们必须搞清楚802.15.4星型网络运行的基本逻辑。这不同于简单的点对点通信，协调器作为网络的中心，需要扮演管理者角色。
2.1 为什么选择非信标使能（Non-beacon）星型网络？
802.15.4网络有两种基本模式：信标使能（Beacon-enabled）和非信标使能（Non-beacon）。在信标模式中，协调器会周期性地广播信标帧（Beacon），用于同步网络、描述超帧结构并宣告是否有待传数据。这种模式适合对时序和功耗有严格调度的场景。
而我这次选择实现的是非信标网络。原因有几个：首先，它的实现相对更简单直接，协调器不需要维护复杂的超帧时序，终端设备也无需严格同步，降低了初始开发的复杂度。其次，在终端设备数量不多、数据流量间歇性的典型传感场景（比如每小时上报一次温湿度），非信标网络允许终端设备绝大部分时间处于深度睡眠，仅在需要通信时唤醒，这能最大化节能。协调器则持续监听信道，随时准备响应。这种“终端设备主导通信”的异步模式，对于许多电池供电的传感器应用来说是更自然的选择。
2.2 核心状态机与模块职责划分
整个系统的软件架构围绕几个核心状态机展开：
协调器（Coordinator）状态机：
- 初始化与信道扫描：上电后，选择一个干扰最小的信道建立网络。
- 监听与关联：持续监听信道，处理终端设备的关联请求，并为其分配短地址。
- 数据中转与维护：接收来自串口或内部定时器的数据，通过间接传输机制发给目标终端；同时跟踪数据包状态，清理失效设备的资源。
终端设备（End Device）状态机：
- 网络发现：主动扫描信道，寻找可用的协调器。
- 关联入网：向选定的协调器发送关联请求，获取网络短地址。
- 轮询与数据交换：周期性向协调器发送轮询请求（Poll Request）来查询是否有下行数据；同时可主动发送上行数据（如按键触发）。
- 低功耗管理：在无网络活动时，进入低功耗模式（如MCU的Stop模式），由定时器或外部中断唤醒。
关键模块“Purger”：这是协调器侧一个至关重要的后台管理模块。它的核心职责是追踪所有已发出但未收到确认的间接传输数据包。每个被追踪的数据包都有一个“寿命”。如果超过寿命（即终端设备长时间未取走数据），Purger会判定该终端设备可能已失联，并触发清理流程，回收其网络地址。这是实现网络自维护、防止资源泄漏的关键。
理解了这些宏观流程，我们就能深入到每个环节的代码实现和细节中去了。
3. 协调器实现详解：从建网到数据管理
协调器是网络的基石，它的稳定性和效率直接决定了整个网络的性能。
3.1 网络启动与信道选择
协调器上电后，第一件事不是立刻广播“我在这里”，而是先“听听环境”。这通过能量检测扫描（ED Scan）来完成。代码会遍历所有可用的信道（例如2.4GHz频段的16个信道），在每个信道上监听一段时间，测量该信道的平均噪声能量。
// 伪代码示例：启动ED Scan mlmeMessage_t *pMsg = MSG_AllocType(mlmeMessage_t); pMsg->msgType = gMlmeScanReq_c; pMsg->msgData.scanReq.scanType = gScanModeED_c; pMsg->msgData.scanReq.scanChannels = CHANNEL_MASK; // 要扫描的信道位图 pMsg->msgData.scanReq.scanDuration = 3; // 在每个信道上的扫描时长基数 MSG_Send(NWK_MLME, pMsg);扫描结束后，MLME会上报gMlmeScanCnf_c确认消息，其中包含每个信道的能量值列表。协调器的策略很简单：选择能量值最低（最安静）的信道作为自己的工作信道。这能最大程度避免与Wi-Fi、蓝牙等其他2.4GHz设备的同频干扰。
实操心得：在实际部署中，单纯的ED扫描可能不够。有些干扰是间歇性的。更稳健的做法是在产品初始化时，让协调器在多个候选信道上进行更长时间的监听（比如每信道5-10秒），并记录能量波动情况，选择最稳定、最安静的信道。甚至可以设计成定期重扫描，在网络性能下降时自动切换信道。
选定信道后，协调器调用MLME-START.request原语，设置PAN ID（可以固定或随机生成）、信道号，并将macAssociationPermit属性设为TRUE，表示允许设备关联。至此，一个静默等待设备加入的非信标网络就建立起来了。
3.2 终端设备关联与精妙的地址管理
这是协调器逻辑中最精巧的部分之一。当终端设备发送关联请求（Associate Request）时，协调器的App_SendAssociateResponse函数被调用。它必须决定是否接受该设备，以及给它分配什么地址。
项目中使用了一个非常高效的方案：用1个字节（8位）的位图mAddressesMap来管理最多4个终端设备的短地址。这适用于小规模网络。
// 地址分配核心逻辑 if(0x0F > mAddressesMap) { // 判断低4位是否全为1（即网络是否已满） uint8_t selectedAddress = 1; // 从地址1开始 while((selectedAddress & mAddressesMap) != 0) { // 寻找第一个为0的位 selectedAddress = selectedAddress << 1; // 左移，检查地址2、4、8 } pAssocRes->assocShortAddress[0] = selectedAddress; // 分配地址 pAssocRes->assocShortAddress[1] = 0x00; requestResolution = gSuccess_c; mAddressesMap |= selectedAddress; // 更新位图，标记该地址已占用 } else { // 网络容量已满 pAssocRes->assocShortAddress[0] = 0xFE; pAssocRes->assocShortAddress[1] = 0xFF; // 0xFFFE表示不分配短地址 requestResolution = gPanAtCapacity_c; }为什么地址是1、2、4、8？这里利用了位运算的特性。selectedAddress初始为1（二进制0000 0001），每次左移一位，得到2(0000 0010)、4(0000 0100)、8(0000 1000)。mAddressesMap的低4位分别对应这4个地址的占用状态（1为占用，0为空闲）。(selectedAddress & mAddressesMap) != 0这个判断，就是检查该地址对应的位是否已被占用。这种设计将地址分配和状态查询的复杂度降到了O(1)，极其高效。
注意事项：这种方案将网络容量硬编码为4个设备。在实际产品中，你需要根据内存和需求扩展。例如，使用一个16位的位图可以管理16个设备（地址1-32768，2的幂次）。或者使用动态地址池链表。但位图法的效率在设备数不多时是无可比拟的。
3.3 间接传输与数据下行流程
在非信标网络中，协调器发给终端设备的数据采用间接传输（Indirect Transmission）。协调器将数据包存入自己的“待发队列”（MAC的间接事务队列），然后等待终端设备主动来“取”。终端设备通过发送MLME-POLL.request来查询并取走数据。
协调器的App_TransmitData函数负责下行数据：
- 检查发送条件：首先确认有设备在线（
mAddressesMap != 0），并且没有过多的数据包积压（mcPendingPackets未超限）。 - 构造数据包：为每个在线的目标设备复制一份数据，填充目标地址（短地址）、源地址（协调器地址）、PAN ID，并关键地设置
txOptions = gTxOptsAck_c | gTxOptsIndirect_c。gTxOptsAck_c要求MAC层进行单播确认，确保数据链路层可靠；gTxOptsIndirect_c则指明这是间接传输。 - 发送并追踪：调用
MSG_Send将MCPS-DATA.request发给MAC层。紧接着，调用Purger_Track函数，将数据包的句柄（msduHandle）和目标设备地址记录到追踪列表中，并递增mcPendingPackets计数器。
// 发送数据并追踪的核心代码片段 mpPacket->msgData.dataReq.txOptions = gTxOptsAck_c | gTxOptsIndirect_c; mpPacket->msgData.dataReq.msduHandle = mMsduHandle++; // 生成唯一句柄 // 添加到Purger追踪列表 ret = Purger_Track(mpPacket->msgData.dataReq.msduHandle, 0, deviceAddress, mCounterLEDs); NR MSG_Send(NWK_MCPS, mpPacket); mcPendingPackets++;这里的关键在于msduHandle。它是一个由应用层维护的、递增的数据包唯一标识符。当MAC层最终完成数据发送（无论成功、失败还是超时），都会通过MCPS-DATA.confirm消息将同一个msduHandle返回给应用层。这样，应用层就能精确地知道是哪个数据包有了结果。
3.4 Purger模块：网络状态的“看门狗”
Purger模块是协调器稳定性的守护神。它的设计目标很明确：识别并清理那些已经失联（沉默）的终端设备。
3.4.1 Purger的工作原理
Purger维护一个固定大小的数组msgTrackArray，用于记录所有已发出但未确认的间接传输数据包。每个记录包含：
msduHandle: 数据包句柄，用于匹配确认消息。destAddressLow/High: 目标设备地址。expirationTime: 数据包过期时间（当前时间 + 预设的生命周期gPurgerExpireInterval）。slotStatus: 槽位状态（已使用/未使用）。
协调器在主循环中定期调用Purger_Check()函数。这个函数遍历追踪列表，检查每个数据包的expirationTime。如果发现某个数据包已经过期（当前时间 >= 过期时间），它就执行以下操作：
- 向MAC层发送一个
MCPS-PURGE.request，请求从MAC的间接队列中清除这个过期数据包。 - 调用应用层注册的回调函数（例如
App_RemoveDevice），通知应用该数据包的目标设备可能已失联。 - 在
App_RemoveDevice中，协调器会将该设备对应的地址位从mAddressesMap中清除（mAddressesMap &= ~(shortAddrLow);），并可能通过LED或串口提示设备断开。
3.4.2 数据确认与正常流程
当终端设备正常轮询并取走数据后，协调器的MAC层会收到来自该设备的MAC层确认（ACK），随后协调器应用层会收到MCPS-DATA.confirm消息，状态为gSuccess_c。
case gMcpsDataCnf_c: if(mcPendingPackets) { mcPendingPackets--; } /* 从Purger追踪列表中移除该数据包 */ ret = Purger_Remove(pMsgIn->msgData.dataCnf.msduHandle); break;此时，Purger_Remove函数会根据msduHandle找到对应的追踪记录，并将其标记为未使用（slotStatus = mPurgerUnusedSlot_c），完成一次正常的数据传输闭环。
3.4.3 超时判定与设备移除
Purger的巧妙之处在于利用数据包超时来推断设备状态。如果一个设备长时间不发送Poll请求（比如电池耗尽、移出范围或故障），那么发往它的所有数据包都会在Purger中陆续过期。
项目代码中有一个重要的逻辑：并非一个数据包过期就立刻踢掉设备。这可以避免因临时信道干扰导致的偶发性超时。更常见的策略是，为每个设备维护一个“超时计数器”。在App_RemoveDevice或类似回调中，当某个设备的过期数据包数量累计达到一个阈值（例如3个），协调器才最终判定该设备失联，并执行地址回收等清理操作。原文中MC1322x的示例正是采用了这种策略（maPacketDrops[deviceHandler]++，达到3则移除设备）。
避坑指南：
gPurgerExpireInterval（数据包生命周期）的设置至关重要。设得太短，网络稍有延迟就可能误判设备离线；设得太长，设备真实失效后地址回收太慢，影响新设备加入。这个值需要根据终端设备的轮询间隔（Poll Interval）来调整。一个经验法则是：生命周期应大于终端设备正常的最大轮询间隔的2-3倍，为网络延迟和重传留出余量。例如，设备每10秒轮询一次，生命周期可以设为30-45秒。
4. 终端设备实现详解：入网、轮询与低功耗
终端设备作为网络的边缘节点，其核心任务是节能、可靠地接入网络并交换数据。
4.1 主动扫描与网络发现
终端设备上电后，首要任务是找到可加入的网络。它通过主动扫描（Active Scan）来实现。与协调器最初的ED扫描不同，主动扫描会主动在每个信道上发送信标请求命令（Beacon Request），并监听来自协调器的信标（Beacon）响应。
// 终端设备启动主动扫描 pMsg->msgType = gMlmeScanReq_c; pMsg->msgData.scanReq.scanType = gScanModeActive_c; // 关键：设置为主动扫描 pMsg->msgData.scanReq.scanChannels = CHANNEL_MASK_ALL; // 扫描所有信道 MSG_Send(NWK_MLME, pMsg);扫描结束后，MLME会上报MLME-SCAN.confirm，其中包含一个panDescriptor_t结构体列表，描述了所有被发现网络的信息。终端设备需要从中选择一个最优的网络进行关联。选择策略通常基于：
- 关联许可：检查信标中的
Association Permit位是否为1（允许关联）。 - 信号质量：选择
linkQuality（链路质量指示，LQI）最高的网络，这通常意味着信号最强、距离最近。 - 网络类型：确认
SuperframeSpec中的信标序（Beacon Order）为0xF，表明这是一个非信标网络。
// 选择最佳协调器的逻辑（简化） if( (pPanDesc->superFrameSpec[1] & gSuperFrameSpecMsbAssocPermit_c) && ((pPanDesc->superFrameSpec[0] & gSuperFrameSpecLsbBO_c) == 0x0F) ) { if(pPanDesc->linkQuality > bestLinkQuality) { // 保存这个更好的协调器信息 FLib_MemCpy(&mCoordInfo, pPanDesc, sizeof(panDescriptor_t)); bestLinkQuality = pPanDesc->linkQuality; } }4.2 发送关联请求与能力声明
选定目标协调器后，终端设备构造并发送MLME-ASSOCIATE.request。这个消息中除了携带��标协调器的地址、PAN ID、信道外，还有一个关键字段：能力信息（Capability Information）。
pAssocReq->capabilityInfo = gCapInfoAllocAddr_c; // 0x80这个8位字段向协调器声明了设备的能力：
- Bit 7 (Allocate Address): 设为1，表示“请为我分配一个16位短地址”。如果设为0，协调器会分配特殊地址0xFFFE，这意味着设备后续必须使用其64位扩展地址进行通信，效率较低。
- 其他位：例如设备类型（FFD/RFD）、电源类型（交流/电池）、接收机空闲时是否常开等。协调器可以根据这些信息进行简单的网络资源管理。
发送请求后，设备等待MLME-ASSOCIATE.confirm。如果成功，确认消息中会包含协调器分配的短地址，设备需要保存这个地址用于后续所有通信。
4.3 数据轮询：如何获取下行数据
在非信标网络中，终端设备是通信的发起方。为了获取协调器可能下发的数据，它必须周期性地向协调器发送MLME-POLL.request。这个过程叫做“轮询”。
static void App_ReceiveData(void) { if(mWaitPollConfirm == FALSE) { // 确保上一次Poll确认已收到 mlmeMessage_t *pMlmeMsg = MSG_AllocType(mlmeMessage_t); pMlmeMsg->msgType = gMlmePollReq_c; // 填入之前保存的协调器信息 memcpy(pMlmeMsg->msgData.pollReq.coordAddress, mCoordInfo.coordAddress, 8); memcpy(pMlmeMsg->msgData.pollReq.coordPanId, mCoordInfo.coordPanId, 2); MSG_Send(NWK_MLME, pMlmeMsg); mWaitPollConfirm = TRUE; // 设置等待确认标志 } }轮询间隔是功耗与实时性的权衡：
- 间隔短（如1秒）：数据下行延迟低，协调器有数据能很快被取走，但设备唤醒频繁，功耗高。
- 间隔长（如60秒）：功耗极低，但数据可能在下行队列中等待很长时间。
设备发送Poll请求后，会等待MLME-POLL.confirm。如果状态不是gSuccess_c，通常表示协调器没有待传数据。如果状态是gSuccess_c，则紧接着很可能会收到一个或多个MCPS-DATA.indication消息，里面就是协调器下发的实际数据。
核心机制理解：
MLME-POLL.request本质上是在问协调器：“我有数据吗？”。协调器MAC层收到后，会检查该设备的间接事务队列。如果有，就把数据打包进MLME-POLL.response（实际上可能触发一个或多个MCPS-DATA.indication到设备应用层）；如果没有，就回复一个空的确认。设备应用层在收到gSuccess_c的Poll确认后，需要准备好接收随之而来的数据指示。
4.4 低功耗模式实现要点
低功耗是802.15.4终端设备的灵魂。实现的关键在于让设备在绝大部分时间处于睡眠模式，只在需要通信（发送数据、轮询）或处理定时任务时短暂唤醒。
项目中使用了一个电源管理库（PWRLIB）。其核心流程如下：
- 初始化：
PWRLib_Init()。 - 睡眠判断：在主循环的Idle任务中，检查是否满足睡眠条件（如
mWaitPollConfirm为FALSE，且无其他活动）。 - 进入睡眠：调用
PWR_EnterLowPower()。该函数内部通常会配置一个实时定时器（RTC）作为唤醒源，然后让MCU进入深度睡眠模式（如Stop模式），同时关闭射频收发器。 - 定时唤醒：RTC定时中断将MCU唤醒，设备恢复运行，执行下一次轮询或其他任务。
// 低功耗管理伪代码 void Idle_Task(void) { if(APP_CanSleep()) { // 检查应用层条件 PWR_EnterLowPower(); // 进入低功耗模式，由RTC或外部中断唤醒 } // 唤醒后继续执行主循环 }功耗估算的关键参数：
- 睡眠电流：MCU在深度睡眠模式下的电流，可能低至1μA以下。
- 活动电流：MCU运行且射频收发器工作时的电流，可能为20-30mA。
- 唤醒时间：从睡眠到能够发送第一个数据包所需的时间，通常为几毫秒。
- 轮询周期：决定了活动与睡眠的时间比例。
平均电流 ≈ (活动电流 * 活动时间 + 睡眠电流 * 睡眠时间) / 轮询周期。通过延长轮询周期，可以显著降低平均功耗，使电池寿命达到数月甚至数年。
5. 关键问题排查与实战调试经验
在实际开发和调试中，你会遇到各种各样的问题。下面是我总结的一些常见问题及其排查思路。
5.1 关联失败问题排查
| 问题现象 | 可能原因 | 排查步骤 |
|---|---|---|
| 终端设备扫描不到网络 | 1. 协调器未成功启动。 2. 协调器与设备信道不匹配。 3. 协调器 macAssociationPermit未设置为TRUE。4. 距离过远或物理遮挡。 | 1. 确认协调器串口有启动成功日志。 2. 核对协调器与设备代码中的信道扫描掩码（ scanChannels）。3. 检查协调器 MLME-START.request参数。4. 拉近距离，排除干扰。 |
| 扫描到网络但关联请求被拒 | 1. 协调器网络已满（mAddressesMap == 0x0F）。2. 协调器资源（内存）不足。 | 1. 检查协调器mAddressesMap值，确认是否有地址可用。2. 查看协调器串口是否有“Pan at capacity”或内存分配失败日志。 |
| 关联请求无响应 | 1. 设备发送的协调器地址或PAN ID错误。 2. 空中数据包冲突或丢失。 | 1. 对比设备保存的mCoordInfo与协调器实际地址/PAN ID。2. 在设备端增加重试机制，连续多次关联失败后重新扫描。 |
调试技巧：在协调器和设备端都开启详细的调试串口输出。在关键步骤（如收到扫描请求、关联请求、分配地址）打印日志。使用逻辑分析仪或带时间戳的串口工具，可以清晰看到双方交互的时序，更容易定位是请求没发出，还是响应没收到。
5.2 数据传输不稳定问题排查
| 问题现象 | 可能原因 | 排查步骤与解决方案 |
|---|---|---|
| 终端设备收不到下行数据 | 1. 设备未发送Poll请求或间隔太长。 2. 协调器Purger过早清除了数据包。 3. 数据包在MAC层发送失败（ACK未收到）。 | 1. 确认设备轮询逻辑正常，mWaitPollConfirm标志位能正确翻转。2. 增加协调器 gPurgerExpireInterval，确保大于设备轮询间隔。3. 检查 MCPS-DATA.confirm状态，如果是gChannelAccessFailure_c或gNoAck_c，需考虑信道竞争或距离问题。 |
| 上行数据（设备到协调器）丢失 | 1. 设备发送时未请求ACK。 2. 协调器应用层处理数据太慢，导致缓冲区溢出。 | 1. 确保设备发送MCPS-DATA.request时txOptions包含gTxOptsAck_c。2. 在协调器端，检查 MCPS-DATA.indication的处理函数是否高效，避免阻塞。如果数据量大，需实现流控。 |
| 设备被协调器误移除 | 1. Purger超时时间设置过短。 2. 设备轮询间隔不稳定，有时超时。 3. 网络干扰导致Poll请求或响应丢失。 | 1. 根据设备最坏情况下的轮询间隔，调大Purger超时时间。 2. 在设备端实现自适应的轮询间隔，在网络状况差时适当缩短间隔。 3. 在协调器端实现更宽容的移除策略，如连续多个包超时才移除，而不是一个包超时就计数。 |
5.3 低功耗相关的问题
- 功耗高于预期：首先用电流表测量设备在不同状态（深度睡眠、空闲、发射、接收）下的电流，与芯片数据手册对比。常见原因：
- 软件未正确配置低功耗模式：确认进入睡眠前已关闭所有不必要的外设时钟和模块。
- 唤醒源配置不当：有未被禁用的中断源频繁唤醒MCU。检查所有GPIO中断、定时器中断的配置。
- 轮询间隔太短：这是最主要的原因。根据应用对下行数据延迟的容忍度，尽可能延长轮询间隔。
- 设备睡眠后无法唤醒或通信异���：这通常是硬件或底层驱动问题。检查：
- 射频模块的唤醒时序：睡眠和唤醒时，对射频模块的寄存器配置序列必须严格按照数据手册进行。
- 时钟源切换：睡眠时可能使用低速时钟，唤醒后要确保系统时钟已稳定切换回高速时钟，否则串口、射频等外设工作会不正常。
5.4 跨平台实现的差异：HCS08 vs. MC1322x
原文附录提到了HCS08和ARM7（MC1322x）平台实现的差异，这是一个非常重要的实践点。核心差异在于Purger模块被MAC层的帧过期（Frame Expiration）特性所替代。
在MC1322x的MAC实现中，协调器不再需要自己维护一个Purger追踪列表和定时检查。相反，它通过设置MAC PIB（PAN Information Base）属性来控制间接传输数据包在MAC队列中的存活时间。
// MC1322x 设置帧持久时间 uint8_t time[2] = mDefaultValueOfPersistenceTime; pMsg->msgData.setReq.pibAttribute = gMPibTransactionPersistenceTime_c; pMsg->msgData.setReq.pibAttributeValue = time; MSG_Send(NWK_MLME, pMsg); // 使用非信标超帧间隔替代信标序来计算超时 uint8_t tmp = mDefaultValueOfSuperframeInterval; pMsg->msgData.setReq.pibAttribute = gMPibNBSuperFrameInterval_c; pMsg->msgData.setReq.pibAttributeValue = &tmp; MSG_Send(NWK_MLME, pMsg);当数据包在MAC间接队列中停留时间超过设定的PersistenceTime后，MAC层会自动将其过期，并向应用层上报一个状态为gTransactionExpired_c的MCPS-DATA.confirm消息。应用层只需要监听这个状态，并据此更新对应设备的丢包计数器即可。
这种方式的优势：
- 更符合标准：直接利用了802.15.4标准定义的
macTransactionPersistenceTime属性。 - 减轻应用负担：无需应用层实现复杂的定时追踪和清理逻辑，代码更简洁。
- 可能更高效：超时判断在MAC层完成，时效性更高。
需要注意的适配：当你从一种平台迁移到另一种平台，或者更换不同的MAC协议栈时，必须仔细阅读文档，确认网络维护（如设备失联判断）是由应用层（Purger模式）还是MAC层（帧过期模式）负责，并相应调整你的应用逻辑。
