1. 为什么FreeRTOS工程在Ozone里“看不见”内核状态——调试环境失效的底层真相我第一次把刚移植好的FreeRTOS工程拖进Ozone时界面干净得让人发慌寄存器窗口全灰调用栈空空如也断点打下去毫无反应连最基础的main()函数入口都标不出来。不是J-Link没连上——设备管理器里明晃晃显示着“SEGGER J-Link”也不是Ozone没装对——启动后能正常识别芯片型号。问题出在更隐蔽的地方Ozone根本没意识到你跑的是FreeRTOS它只当这是个裸机程序。它在等一个“操作系统感知层”的握手信号而这个信号必须由开发者亲手注入。这背后是调试器与RTOS之间一套被严重低估的协同机制。J-Link本身只是硬件通道Ozone是可视化前端真正决定你能看到多少内核信息的是RTOS插件RTOS Plugin。它不是Ozone自带的也不是J-Link固件内置的而是一个需要你主动加载、配置、甚至有时要手动编译的独立模块。它的工作原理非常朴素通过读取FreeRTOS内核在RAM中维护的一组特定全局变量比如pxCurrentTCB、pxReadyTasksLists、xListEnd再结合你提供的内核源码结构定义通常是FreeRTOSConfig.h和portmacro.h里的宏把一堆内存地址翻译成“任务名”“状态”“堆栈剩余”这些人类可读的信息。没有它Ozone看到的只是一片内存字节有了它你才能在任务视图里直接点击某个任务跳转到它的上下文才能看到队列长度实时变化才能在中断服务函数里一眼看出哪个任务被唤醒了。网络上大量“Ozone安装教程”止步于“双击Ozone.exe→选择芯片→点Run”这恰恰是新手掉坑的起点。他们以为调试器能自动识别RTOS结果发现所有RTOS相关的视图Task List、Queue List、Semaphore List全是灰色禁用状态然后开始疯狂搜索“No J-Link found”或“Ozone not showing tasks”。其实J-Link找得到Ozone也运行着只是那个关键的“翻译官”——RTOS插件——压根没上岗。更麻烦的是这个插件对FreeRTOS版本、编译器、甚至你用的CMSIS版本都有强依赖。我试过用v10.4.6的FreeRTOS配GCC 10.3编译Ozone自带的插件就报错“symbol pxCurrentTCB not found”换成v10.2.1的插件才正常。这不是Bug是设计使然FreeRTOS的内部数据结构在不同版本间有微调插件必须精确匹配。所以搭建这个环境的第一步从来不是连硬件而是先确认你的FreeRTOS版本号、编译工具链、以及你手头Ozone的版本。三者必须形成一个闭环兼容组合。网上搜到的“Segger Ozone使用教程”大多忽略这点直接教你怎么点按钮结果读者照着做环境永远差最后一公里。真正的起点是你打开Ozone的“Help → About Ozone”看版本号然后去Segger官网查对应版本的RTOS插件支持列表再回头检查你的FreeRTOS源码是否在支持范围内。这个动作看似简单却决定了后续所有调试功能能否激活。很多工程师花半天时间排查J-Link驱动最后发现只是因为Ozone版本太新而项目用的FreeRTOS太老插件不兼容而已。提示Ozone的RTOS插件支持不是“全版本通吃”。Segger官方明确列出每个Ozone版本支持的FreeRTOS最小/最大版本号。例如Ozone v3.20a支持FreeRTOS v9.0.0至v10.4.1但不支持v10.4.2之后的改动。强行使用不匹配的插件Ozone会静默失败不会报错只会让你的RTOS视图永远灰着。2. J-Link硬件选型与固件升级别让物理层成为调试瓶颈很多人以为J-Link就是个“万能烧录器”只要能烧写程序调试肯定没问题。我在给一家做工业传感器的客户做技术支持时就遇到过一个典型场景客户用J-Link EDU Mini调试STM32F407上的FreeRTOSOzone能连上也能单步执行但一设断点就卡死或者任务切换时寄存器值乱跳。换了一台J-Link BASE问题立刻消失。根源不在软件而在J-Link硬件本身的性能边界。J-Link系列硬件差异远不止于价格标签。核心区别在于SWD协议处理能力、内存带宽、以及对复杂RTOS调试指令的支持深度。EDU Mini是教学版其SWD接口的时钟频率上限为4MHz且内部缓存小在频繁读取FreeRTOS内核链表如就绪列表、阻塞列表时数据吞吐跟不上导致Ozone从J-Link读取一个任务结构体要花几十毫秒而FreeRTOS任务切换可能在几微秒内完成结果你看到的永远是“过期快照”。BASE版则支持最高50MHz SWD时钟内置更大缓存能以接近实时的速度同步内核状态。对于Cortex-M3/M4这类中等性能MCU上的FreeRTOSBASE是底线如果项目涉及大量任务、复杂队列操作或高频中断J-Link PLUS或PRO才是稳妥选择。另一个常被忽视的关键点是J-Link固件版本。J-Link不是一次烧录就终身可用的设备它的固件Firmware会随Ozone和J-Link Software更新而迭代。旧固件可能根本不认识新MCU的IDCODE或者对某些RTOS调试指令支持不全。我曾用一台2018年的J-Link BASE调试一款新发布的HK32C030芯片Ozone始终报“Unknown device”直到我用J-Link Commander执行exec UpdateFirmware命令升级固件问题瞬间解决。升级过程极简单下载最新版J-Link Software and Documentation Pack安装后运行J-Link Commander输入connect连接设备再输入exec UpdateFirmware等待几秒即可。这个动作应该成为每次搭建新调试环境前的固定流程而不是等到连不上才想起。还有一点关于“cw32l010支持J-Link版本”的疑问。CW32L010是芯旺微的超低功耗MCU其调试接口基于ARM CoreSight理论上所有J-Link都能支持。但实际中早期J-Link固件v6.x之前未收录该芯片的Flash编程算法导致Ozone能识别芯片却无法擦写Flash。解决方案同样是升级固件并确保J-Link Software包中包含CW32L010的Device Support文件。验证方法很简单在Ozone中新建工程选择Target Device时下拉菜单里能看到“CW32L010”选项且旁边标注“Flash algo: CW32L010_FlashAlgorithm.jlink”就说明支持完备。注意不要轻信“J-Link定义”这类模糊说法。J-Link的“定义”本质是固件软件算法包的组合。同一台J-Link硬件固件版本不同支持的芯片列表就不同Ozone版本不同调用的调试指令集也不同。所谓“支持”必须同时满足硬件能力、固件版本、软件算法三者匹配。3. Ozone工程配置的致命细节从裸机到RTOS的四步跃迁Ozone里创建一个工程远比Keil或IAR里点几下鼠标复杂。它没有向导式界面所有配置都藏在文本化的.jdebug文件里。很多教程教你“File → Open Target Configuration”然后选芯片点OK就以为万事大备。结果一加载FreeRTOS符号表Ozone报错“Could not load symbols from xxx.elf”或者加载成功了但RTOS视图还是灰的。问题往往出在.jdebug文件里那几行不起眼的配置上。第一步Target Interface必须精确匹配你的硬件连接方式。如果你的板子用SWD接口这里必须写SWD如果误写成JTAGOzone会尝试用JTAG时序通信必然失败。更隐蔽的是Speed参数。默认值往往是Auto但在某些长排线或噪声环境下Auto可能选到过高频率导致通信不稳定。我的经验是对Cortex-M3/M4手动设为4000即4MHz反而更稳对M0/M2310001MHz更可靠。这个值不是越高越好而是要在通信成功率和调试响应速度间找平衡点。第二步Symbol File路径必须指向你编译生成的完整ELF文件而非HEX或BIN。ELF文件里包含完整的调试符号Debug Symbols包括变量地址、函数范围、类型定义。HEX/BIN只是纯二进制代码Ozone加载它们只能看到汇编指令看不到任何C语言级别的变量或函数名。我见过太多人把project.hex拖进Ozone然后奇怪为什么找不到xTaskCreate函数。正确做法是在你的构建系统Makefile或IDE里确保arm-none-eabi-gcc链接时加了-g参数并保留.elf输出。Ozone的Symbol File框里必须填入build/project.elf这样的绝对路径。第三步也是最关键的一步RTOS Plugin的加载与配置。这一步不能靠GUI点选必须手动编辑.jdebug文件。在文件末尾添加如下段落// --- RTOS Plugin Configuration --- RTOS_PLUGIN FreeRTOS RTOS_PLUGIN_PATH $TOOLKIT_DIR$/RTOSPlugin/FreeRTOS/FreeRTOSPlugin.dll RTOS_PLUGIN_CONFIG FreeRTOSConfig.h RTOS_PLUGIN_SYMBOLS pxCurrentTCB,pxReadyTasksLists,xListEnd,uxTopUsedPriority其中RTOS_PLUGIN_PATH指向Ozone安装目录下的插件DLL路径RTOS_PLUGIN_CONFIG是你项目里FreeRTOSConfig.h的绝对路径RTOS_PLUGIN_SYMBOLS是FreeRTOS内核中几个核心全局变量的名字。这些变量名必须与你实际使用的FreeRTOS版本完全一致。比如v10.4.x之后uxTopUsedPriority改名为uxTopReadyPriority如果还写旧名字插件就找不到入口整个RTOS视图失效。第四步Memory Map的显式声明。Ozone默认按芯片手册预设内存布局但FreeRTOS的堆heap通常放在RAM里一个自定义区域比如0x20000000起始的16KB。如果Ozone不知道这块内存是“可读写的RAM”它就不会去那里扫描任务控制块TCB。必须在.jdebug里添加MEM_MAP RAM, 0x20000000, 0x00004000, READ_WRITE这行告诉Ozone从0x20000000开始的16KB0x4000字节是可读写的RAM区域插件可以放心在这里搜索TCB结构体。漏掉这行插件可能只在默认的SRAM区域查找而你的FreeRTOS heap偏偏放在别处结果自然是“找不到任务”。提示.jdebug文件是纯文本修改后保存下次Ozone加载工程时自动生效。不要试图在Ozone GUI里修改这些高级设置——它没有对应界面。养成习惯每次新建工程后先用文本编辑器打开.jdebug对照上述四步逐项检查。这比事后花两小时排查“为什么看不到任务”高效得多。4. FreeRTOS内核符号的精准定位手把手教你从源码里挖出调试钥匙Ozone的RTOS插件不是魔法它需要你提供几把“钥匙”——也就是FreeRTOS内核中几个关键全局变量的准确地址和结构定义。网络上流传的“freertos内核源码深度解析”文章大多聚焦在调度算法和队列实现却极少讲这些变量在内存中如何布局而这恰恰是调试环境能否跑起来的技术基石。我们以最常用的pxCurrentTCB为例。它是FreeRTOS的“当前任务控制块指针”Ozone靠它定位正在运行的任务。它的定义在tasks.c里PRIVILEGED_DATA TCB_t * volatile pxCurrentTCB NULL;注意两个关键词volatile告诉编译器不要优化掉这个变量的读写和PRIVILEGED_DATA这是一个宏在portmacro.h里定义通常展开为__attribute__((section(.privileged_data)))。这意味着pxCurrentTCB被放在一个叫.privileged_data的自定义段里而不是默认的.data段。如果你的链接脚本Linker Script里没有为.privileged_data段分配地址或者Ozone的符号加载器没被告知这个段的位置pxCurrentTCB就会“消失”。所以第一步是确认你的链接脚本是否包含了.privileged_data段。打开你的STM32F407.ld或其他MCU对应的ld文件找到SECTIONS部分确保有类似. ALIGN(4); .privileged_data (NOLOAD) : { *(.privileged_data) } RAM这行代码告诉链接器把所有标记为.privileged_data段的变量放在RAM里并且不初始化NOLOAD因为FreeRTOS会在运行时自己初始化。第二步验证pxCurrentTCB是否真的被编译进了ELF文件。用命令行工具检查arm-none-eabi-nm build/project.elf | grep pxCurrentTCB如果输出类似20000120 D pxCurrentTCB说明地址0x20000120处有一个DData类型的符号一切正常。如果没输出或者输出是UUndefined说明链接失败需要回查链接脚本和编译选项。第三步理解TCB_t结构体的内存布局。Ozone插件需要知道TCB_t里每个字段的偏移量才能从pxCurrentTCB地址开始正确解析出任务名、堆栈指针、状态等信息。这个结构体定义在task.h里但它的具体大小和字段顺序取决于FreeRTOSConfig.h里的配置。比如#define configUSE_TRACE_FACILITY 1 // 如果为0TCB_t里就不含uxTCBNumber字段 #define configUSE_MUTEXES 1 // 如果为0TCB_t里就不含xMutexesHeld字段因此Ozone插件必须加载你项目里真实的FreeRTOSConfig.h而不是随便找个模板。插件会根据这个头文件里的宏定义动态生成TCB_t的结构描述。这也是为什么RTOS_PLUGIN_CONFIG必须指向你工程里的FreeRTOSConfig.h而不是Ozone自带的示例文件。最后一步处理xListEnd和pxReadyTasksLists这类数组变量。pxReadyTasksLists是一个指针数组长度为configMAX_PRIORITIES。Ozone插件需要知道这个数组的起始地址和元素个数才能遍历所有就绪任务。它的定义是PRIVILEGED_DATA List_t pxReadyTasksLists[configMAX_PRIORITIES];同样它也在.privileged_data段里。xListEnd则是链表的哨兵节点定义在list.c里PRIVILEGED_DATA static List_t xListEnd;插件通过xListEnd的地址就能顺着pxReadyTasksLists[i].pxIndex找到每个优先级队列的头节点再遍历整个链表把所有任务都“抓”出来。这个过程高度依赖于你编译时configMAX_PRIORITIES的值是否被正确传递给了插件。如果插件用的是默认值10而你的FreeRTOSConfig.h里设的是5插件就会多读5个不存在的数组元素导致解析错误。经验调试初期如果RTOS视图不显示任务第一件事不是怀疑Ozone或J-Link而是用arm-none-eabi-nm检查这几个关键符号是否存在且地址合理。90%的问题根源都在符号没链接进去或者链接到了错误的内存段。5. 实战排错链路从“No J-Link Found”到任务视图全亮的七次心跳搭建环境的过程本质上是一次精密的系统联调。任何一环出错都会表现为顶层的“连不上”或“看不到”。我整理了一套标准化的七步排错链路每一步都对应一个确定的故障域避免在无关环节浪费时间。这套流程是我帮二十多个客户现场解决问题后沉淀下来的不是理论推演而是血泪教训。第一步物理层心跳Physical Pulse目标确认J-Link硬件与PC的USB通信正常。操作拔掉J-Link打开Windows设备管理器观察“通用串行总线控制器”下是否有黄色感叹号。插回J-Link看是否出现“SEGGER J-Link”条目。如果无反应换USB线、换USB口、换电脑测试。这是最底层必须先过。我曾遇到过一根USB线数据线完好但VBUS供电线虚焊导致J-Link供电不足Ozone反复报“J-Link not found”换了线立刻解决。第二步固件层心跳Firmware Pulse目标确认J-Link固件版本支持你的MCU。操作运行J-Link Commander输入connect选择你的MCU型号如STM32F407VG看是否成功连接并显示Core ID。如果报“Unknown device”立即执行exec UpdateFirmware。这一步绕过Ozone直连硬件能快速隔离是固件问题还是软件配置问题。第三步Ozone层心跳Ozone Pulse目标确认Ozone能识别J-Link并建立基本通信。操作打开OzoneFile → Connect to J-Link看右下角状态栏是否显示“Connected to J-Link”。如果显示“Not connected”检查Ozone是否以管理员权限运行某些USB驱动需要或尝试重启Ozone。这一步成功说明J-Link和Ozone的桥梁已通。第四步Target层心跳Target Pulse目标确认Ozone能正确访问MCU的调试端口。操作在Ozone里File → Open Target Configuration选择你的MCU型号点OK。然后Target → Connect。如果弹出“Cannot connect to target”检查.jdebug里的Interface和Speed是否匹配硬件如果连接成功但显示“Core: Unknown”说明Ozone的芯片数据库没加载需检查安装包是否完整。第五步Symbol层心跳Symbol Pulse目标确认Ozone能加载并解析你的ELF文件。操作File → Load Symbol File选择project.elf。如果报错“Could not load symbols”用arm-none-eabi-nm检查ELF文件是否真有符号如果无报错但变量窗口里看不到任何全局变量说明链接脚本没把.data/.bss段映射到正确RAM地址需检查链接脚本中的MEMORY和SECTIONS定义。第六步RTOS Plugin层心跳RTOS Pulse目标确认RTOS插件已加载且能找到关键符号。操作View → RTOS → Tasks如果视图打开但为空点View → RTOS → Plugin Info看插件状态是否为“Loaded”。如果显示“Failed”检查.jdebug里的RTOS_PLUGIN_PATH路径是否正确RTOS_PLUGIN_CONFIG指向的FreeRTOSConfig.h是否真实存在且路径无中文空格。插件日志会在此窗口显示详细错误比如“Symbol pxCurrentTCB not found”这就是精准的修复指令。第七步Memory Map层心跳Memory Pulse目标确认Ozone知道FreeRTOS heap所在的RAM区域。操作View → Memory Browser手动输入pxCurrentTCB的地址从arm-none-eabi-nm查到看能否读出有效数据。如果读出全是0x00000000说明Ozone没把这块内存识别为RAM必须在.jdebug里添加MEM_MAP行指定该区域为READ_WRITE。这一步成功任务视图里就会开始出现第一个任务。这七步每一步都是一个独立的“心跳”只有前一步成功才能进行下一步。跳过任何一步都会陷入“症状相似、原因各异”的迷雾。比如很多人卡在第七步却去重装J-Link驱动徒劳无功。记住No J-Link Found是物理层问题No Tasks Found是Memory Map或Plugin问题二者天壤之别。6. 超越基础用Ozone深度挖掘FreeRTOS的隐藏状态当任务视图、队列视图都亮起调试环境才算真正“活”了。但这只是开始Ozone的强大在于它能把FreeRTOS的“黑盒”变成透明的“玻璃盒”。我分享几个在实际项目中救过命的深度技巧它们不写在任何官方文档里却是资深工程师的日常武器。技巧一堆栈溢出的实时预警FreeRTOS的configCHECK_FOR_STACK_OVERFLOW只在任务切换时检查且只能触发vApplicationStackOverflowHook你得在钩子函数里加断点才能捕获。Ozone提供更优雅的方案利用pxCurrentTCB-pxTopOfStack和pxCurrentTCB-pxStack计算当前堆栈使用量。在Ozone的“Watch”窗口里添加表达式(pxCurrentTCB-pxTopOfStack - pxCurrentTCB-pxStack) / sizeof(StackType_t)这个值就是已用堆栈深度单位字。再添加一个常量configMINIMAL_STACK_SIZE对比两者。当前者接近后者时说明堆栈快满了。你可以把这个Watch表达式保存为.watch文件每次调试自动加载比在代码里加printf高效十倍。技巧二队列长度的图形化追踪xQueueSend和xQueueReceive是高频调用函数传统断点会严重拖慢系统。Ozone的“Trace”功能可以无侵入式记录。先在queue.c里找到xQueueGenericSend函数入口右键设为“Trace Point”。然后Target → Start Trace运行几秒后Target → Stop Trace。在View → Trace → Trace View里你会看到一条时间轴上面标记了每次队列发送的时刻、参数队列句柄、消息大小。点击任意一次发送右侧Call Stack会显示当时是哪个任务在调用Variables窗口会显示该队列的当前长度。这比翻日志快一百倍。技巧三中断嵌套深度的可视化portSET_INTERRUPT_MASK_FROM_ISR()和portCLEAR_INTERRUPT_MASK_FROM_ISR()是关/开中断的宏它们修改basepri寄存器。Ozone的“Register”窗口里BASEPRI寄存器会实时变化。你可以把它拖到Watch窗口再添加一个表达式(BASEPRI 0xFF) ? (0xFF - (BASEPRI 0xFF)) : 0这个表达式把BASEPRI值转换成当前屏蔽的优先级数数值越大屏蔽级别越高。当它从0跳到1说明进入了一级中断再跳到2说明发生了中断嵌套。配合ITM打印你能精确知道哪段代码引发了深度嵌套从而优化中断服务函数。技巧四任务切换的因果链分析Ozone的“Task Switch”视图默认只显示切换事件。但如果你在.jdebug里启用TRACE_TASK_SWITCHING需在FreeRTOSConfig.h里定义configUSE_TRACE_FACILITY 1再配合Ozone的Trace功能就能看到每次切换的完整上下文谁触发了切换是vTaskDelay还是xQueueReceive阻塞切换目标是谁切换前后堆栈指针的变化。这在排查“任务莫名挂起”或“CPU占用率异常高”时是无可替代的证据。最后一个小技巧Ozone的“Scripting”功能。它支持JavaScript脚本自动化。比如写一个脚本每5秒自动读取所有任务的usStackHighWaterMark算出最小值如果低于阈值就弹窗警告。这比人工监控高效得多。脚本存放在Ozone安装目录的Scripts文件夹里启动时自动加载。这才是真正把调试器变成生产力工具的玩法。7. 避坑清单那些让Ozone调试FreeRTOS失败的隐形陷阱即使你严格遵循了所有步骤仍可能掉进一些极其隐蔽的坑里。这些坑不报错不崩溃只是让你的调试体验大打折扣甚至产生误导性结论。我把它们整理成一份“避坑清单”每一条都来自真实项目现场。陷阱一编译器优化等级与调试符号的冲突-O2或-O3优化会内联函数、删除未使用变量、重排代码顺序。FreeRTOS的vTaskStartScheduler()函数里有个无限循环for( ;; )如果编译器认为这个循环里没做任何事可能会把它优化掉导致Ozone的“Run to Cursor”功能失效光标永远停不下来。解决方案在tasks.c顶部添加#pragma GCC optimize (O0)对整个文件禁用优化或者在FreeRTOSConfig.h里定义configASSERT_DEFINED让所有configASSERT()语句强制保留它们能阻止编译器过度优化。陷阱二CMSIS版本与Ozone的兼容性断层CMSIS是ARM官方的芯片抽象层不同版本的CMSIS对SCB-VTOR向量表偏移寄存器的访问方式不同。Ozone的RTOS插件在初始化时会读取VTOR来定位中断向量表从而找到PendSV_Handler地址这是FreeRTOS任务切换的入口。如果CMSIS版本太新而Ozone插件是为旧CMSIS写的它可能读错VTOR值导致插件找不到PendSV Handler进而无法关联任务切换事件。验证方法在Ozone里View → Register手动读SCB-VTOR看值是否是你链接脚本里设置的向量表起始地址如0x08000000。如果不符降级CMSIS或升级Ozone。陷阱三.stack段与FreeRTOS堆的地址重叠很多链接脚本把.stack段主堆栈和FreeRTOS的heap都放在同一块RAM里比如0x20000000起始的64KB。如果主堆栈用得太多会覆盖FreeRTOS heap的头部导致pxCurrentTCB被破坏。Ozone里看到的任务列表会突然清空或者显示乱码任务名。解决方案在链接脚本里把.stack段单独划一块小内存如0x20000000起始的2KB把FreeRTOS heap放在另一块如0x20000800起始的62KB中间留出保护间隙。陷阱四configUSE_PORT_OPTIMISED_TASK_SELECTION的副作用这个宏开启后FreeRTOS用位运算代替循环查找最高优先级就绪任务性能提升明显。但它改变了uxTopUsedPriority变量的更新逻辑——它不再实时反映最高优先级而只在有更高优先级任务就绪时才更新。Ozone的RTOS插件依赖这个变量来确定要扫描多少个就绪列表。如果它滞后插件就会漏掉高优先级任务。我的建议调试阶段关闭此宏#define configUSE_PORT_OPTIMISED_TASK_SELECTION 0等调试完成再开启。陷阱五configGENERATE_RUN_TIME_STATS的定时器干扰这个功能需要你提供一个portGET_RUN_TIME_COUNTER_VALUE()函数通常用SysTick或TIM定时器实现。但如果这个定时器的中断优先级设置不当比如高于FreeRTOS的configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY就会导致在临界区taskENTER_CRITICAL()里被抢占引发内核崩溃。Ozone里表现为随机断点、寄存器值错乱。解决方案确保统计定时器的优先级数值大于即优先级更低configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY例如后者设为5前者就设为6或7。这些陷阱的共同特点是它们不违反任何语法或链接规则编译能过程序能跑只是调试体验崩坏。它们之所以存在是因为FreeRTOS、Ozone、J-Link、编译器、CMSIS这五个组件各自遵循自己的规范而它们之间的交界处正是bug滋生的温床。唯一可靠的防御是建立一套标准化的“调试模式”构建配置——所有陷阱相关的宏在调试版里统一关闭或降级等功能验证完毕再切回发布版配置。