1. 先说一下这次故障的现场如果你也是 STM32CubeProgrammer 的日常用户并且近期把工具升到了 2.23.0那这篇文章应该能帮你省下一块儿硬盘。我在 macOS 上遇到了一个很诡异的现象电脑可用空间莫名其妙地快速下降刚开始以为是 Time Machine 本地快照失控又以为是 Xcode 缓存爆炸最后用du一层层往下查才发现真凶居然是 STM32CubeProgrammer 自己留下的一个日志文件。这个文件叫Updater_Gui_Log.txt在 macOS 上位于~/Library/Logs/STMicroelectronics/STM32Cube/目录下。它在一个小时内从几 KB 涨到了 30 多 GB而且还在继续涨。我亲眼看着它从 30GB 跳到 31GB磁盘警告弹了好几次只能先把工具杀掉才止住。这个现象有一个非常明显的特征它只在 macOS 系统网络配置处于某种特殊状态时出现。如果你的网络环境是普通默认配置STM32CubeProgrammer 基本不会产生这么大日志。我后来把系统网络环境恢复了默认并重启工具日志就不再增长说明问题就出在软件“更新检查”子系统和网络配置之间的冲突上。先说结论后面再展开完整过程问题与你的工程代码无关与 ST-Link 驱动无关更与 STM32CubeProgrammer 的下载、烧录、调试等主功能无关。它是工具自带的更新器在无法完成网络访问时疯狂重试并且每重试一次就把完整错误栈写进同一个日志文件文件没有任何轮转机制于是无限膨胀。解决办法也不复杂关掉自动更新检查必要时把日志重定向到空设备再顺手清掉已经占了几十 GB 的老文件。2. 几十 GB 的日志是怎么一步步“养”出来的2.1 更新器到底在后台做了什么STM32CubeProgrammer 安装后会包含一个独立的更新器组件负责连接厂商服务器检查当前工具是否有新版本。每次启动主程序这个更新器都会尝试发起网络请求获取版本信息。正常情况下它拿到服务器的响应在界面上显示“当前已是最新版本”日志里只写几行记录整个过程悄无声息。但在某些网络环境下这个更新器请求会失败。失败后程序并没有优雅地停下来而是进入一个“连接失败 - 等待 - 立刻重试 - 再失败 - 再重试”的循环。每一次循环都会向Updater_Gui_Log.txt追加若干行日志。由于这个循环频率很高磁盘写入量非常可观。我做过一个简单的计时测试在特定网络环境下启动工具让它跑 5 分钟日志文件新增了大约 600 MB折合下来每秒 2 MB 左右。如果一直放任不管一天就是上百 GB小容量的固态硬盘根本扛不住。2.2 为什么 macOS 场景特别容易被触发macOS 上的开发者经常会使用一些带虚拟网卡的联网配置工具比如做网络调试、流量抓包或者协议分析时会在系统层面创建一个虚拟接口然后把大量系统流量“路由”进这个虚拟接口里处理。这种配置在 macOS 上非常常见但它会改变系统全局的网络行为。STM32CubeProgrammer 的更新器并不会感知这类虚拟网卡的存在。它只是机械地向服务器发起 HTTPS 请求。当这个请求经过一层特殊的网络转换后握手阶段经常会出现证书校验失败、连接超时、被重置等异常。更新器拿到异常结果后触发了修复逻辑但修复得并不好没有设置重试次数上限也没有做指数退避导致日志一路猛涨。我在 Windows 和 Linux 下也试过同样版本的 STM32CubeProgrammer这两个平台在普通网络环境下没有出现这种问题。因此可以判断这是更新器与 macOS 系统网络层的兼容性 bug而不是磁盘或者工具安装包的问题。2.3 一个关键日志文件的位置在继续往下走之前先把这个日志的位置整理出来方便你快速检查操作系统常见路径macOS~/Library/Logs/STMicroelectronics/STM32Cube/Updater_Gui_Log.txtWindows%APPDATA%\STMicroelectronics\STM32Cube\Updater_Gui_Log.txtLinux~/.local/share/STMicroelectronics/STM32Cube/Updater_Gui_Log.txt需要注意路径里的STMicroelectronics/STM32Cube目录在不同版本中可能略有差异比如有的版本会在Application Support下有的会在Preferences下。如果找不到直接在整个用户目录里搜文件名就行find ~ -name Updater_Gui_Log.txt -size 100M 2/dev/null这条命令会找出大于 100 MB 的日志文件几秒钟就能定位到问题文件。3. 一步步排查定位“写日志的元凶”3.1 先用 du 判断磁盘空间去向遇到磁盘空间快速下降第一件事不是急着删东西而是先找到空间到底去哪了。我习惯从用户目录开始逐层探查du -sh ~/* 2/dev/null | sort -rh | head -20执行完会列出用户目录下占用最大的前 20 项。如果~/Library排在最前面再往下钻du -sh ~/Library/Logs/* 2/dev/null | sort -rh | head -10当时我在~/Library/Logs/STMicroelectronics/STM32Cube/目录下看到了一个文件名带Updater的日志文件大小已经非常夸张后面再执行ls -lh ~/Library/Logs/STMicroelectronics/STM32Cube/Updater_Gui_Log.txt输出显示文件大小为30G。到这里问题基本锁定了。3.2 用 lsof 查看是谁在持续写入只看到文件大还不够还需要确认是哪个进程在往里面写。macOS 上我一般用lsoflsof ~/Library/Logs/STMicroelectronics/STM32Cube/Updater_Gui_Log.txt输出结果里会列出持有该文件句柄的进程名。如果显示的是 STM32CubeProgrammer 主程序或者它的更新器进程那么写入源就找到了。我当时的输出里能看到一个进程名字里带Updater或STM32CubeProgrammer持有这个文件用于追加写入。这个进程就是制造几十 GB 日志的“元凶”。3.3 实时观察日志增长为了确认它确实是在持续增长用tail看一眼最新内容tail -n 50 ~/Library/Logs/STMicroelectronics/STM32Cube/Updater_Gui_Log.txt日志里出现大量重复的报错比如“访问更新服务器失败”“连接超时”“正在重试”之类的内容。因为同一个错误在极短时间被反复写入日志文件才会迅速膨胀。这里有一个小技巧在tail命令前面加一个时间戳转换能更直观地看出写入频率tail -f ~/Library/Logs/STMicroelectronics/STM32Cube/Updater_Gui_Log.txt | awk { print strftime(%F %T), $0 }执行后每行日志前面都会带上精确到秒的时间。如果同一行错误每秒出现很多次说明写入循环非常猛烈。3.4 比较网络环境变化前后的差异锁定文件后下一步是确认根因。我先把系统网络环境恢复到普通状态然后退出 STM32CubeProgrammer重新启动再次观察日志文件大小。步骤是这样的退出 STM32CubeProgrammer在 macOS 系统设置里关闭之前开启的特殊网络配置把网络恢复为默认删除已经膨胀的日志文件重新打开 STM32CubeProgrammer结果非常明显日志文件只是新生成了一小段内容只有启动信息和一次正常的更新检查记录之后就再也不涨了。这就确认了问题与异常网络配置强相关。4. 彻底止血的几种可落地方案4.1 最直接的方法恢复网络默认配置如果你不想对工具做任何“手术”最干净的做法是恢复 macOS 网络默认状态。具体操作很简单打开“系统设置 - 网络”把之前启用的虚拟网卡关闭或者把网络配置切回正常状态然后重启 STM32CubeProgrammer。这个方案的优点是操作最简单而且从根上解决了问题。缺点是你可能确实需要那种特殊网络环境来做其他工作不能为了一个日志文件放弃整个环境。所以接下来给出几个不用改网络配置也能止住的方案。4.2 从 GUI 里关掉自动更新检查STM32CubeProgrammer 主界面有一个 Update 相关菜单通常在Help菜单下面或者打开设置页面能看到“自动检查更新”的开关。不同版本菜单位置不一致但核心逻辑是一样的打开 STM32CubeProgrammer进入Help - Check for Updates或Preferences相关入口取消“启动时自动检查更新”或“自动下载更新”的选项重启工具要注意的是单纯点击“Check for Updates”并不等于关闭自动检查你需要找的是那个表示“自动保持更新”或“打开工具时检查更新”的开关。如果界面上实在找不到可以去看配置文件这是下面要说的。4.3 修改配置文件禁用更新逻辑STM32CubeProgrammer 的配置写在用户目录下。在 macOS 上常见位置是~/Library/Preferences/STMicroelectronics/STM32CubeProgrammer/或者~/Library/Application Support/STMicroelectronics/STM32Cube/目录里会有一个.ini或.conf后缀的配置文件。你可以用下面命令搜一下里面与更新相关的字段grep -i update ~/Library/Preferences/STMicroelectronics/STM32CubeProgrammer/*.ini 2/dev/null不同版本的键名可能不同但基本逻辑都是把真值改成false或0。我在某个版本里见过这类配置[UPDATE_CHECK] enablefalse改完之后保存文件重启工具。如果重启后配置被重置说明程序内部有强制刷新逻辑可以给文件加上只读权限chmod 444 ~/Library/Preferences/STMicroelectronics/STM32CubeProgrammer/*.ini但这样做有一定风险如果工具升级时往配置文件写东西会失败。我更推荐用禁用更新器可执行文件的方式。4.4 直接让更新器“罢工”这是一个比较硬核但很有效的办法找到更新器对应的可执行文件把它改名或移除执行权限主程序启动时找不到更新器自然就跳过了更新流程。在 macOS 上STM32CubeProgrammer 安装在/Applications/STM32CubeProgrammer/下。安装目录里的STM32CubeProgrammer.app是一个应用包真正的可执行文件在/Contents/MacOS/下面更新器组件可能以单独二进制的形式存在或者放在子目录里。我当时的操作是cd /Applications/STM32CubeProgrammer/STM32CubeProgrammer.app/Contents/MacOS/ ls -la看到主程序和一个Updater相关的文件后执行mv Updater_Gui Updater_Gui.disabled如果找不到叫Updater_Gui的文件就用find搜一下安装目录里所有名字带 update 的文件find /Applications/STM32CubeProgrammer -iname *updater* -o -iname *update* 2/dev/null然后把找到的更新器可执行文件改个名字。之后启动主程序会提示找不到更新组件但烧录、调试等功能完全不受影响。这个方法我在 2.23.0 这个版本上验证过稳定运行一周没有复发。4.5 把日志文件重定向到空设备如果你不想禁用更新器希望保留“检查更新”的功能但又不想让日志占满磁盘可以把日志文件改成指向/dev/null的符号链接。这样无论程序写多少内容都会被系统丢弃。操作分三步# 1. 先退出 STM32CubeProgrammer # 2. 将现有日志备份或直接删除 mv ~/Library/Logs/STMicroelectronics/STM32Cube/Updater_Gui_Log.txt ~/Library/Logs/STMicroelectronics/STM32Cube/Updater_Gui_Log.txt.bak # 3. 建立软链 ln -s /dev/null ~/Library/Logs/STMicroelectronics/STM32Cube/Updater_Gui_Log.txt这样处理之后更新器照样运行照样会去访问服务器但所有日志内容都写进了系统的空设备里磁盘占用永远不会增加。这里有一个细节如果日志文件正在被进程占用mv之后可能会出现句柄还指向旧文件的情况。最稳妥的方案是先退出 STM32CubeProgrammer再执行上面的命令。5. 日志里到底写了些什么为什么能写这么快5.1 重复出现的错误模式我截取了日志开头和结尾的一部分对比发现内容高度重复基本上都是同一个错误每隔很短时间就被重新记录一次。典型的内容结构大致是这样2025-01-xx 10:23:01.123 [ERROR] Update server connection failed. 2025-01-xx 10:23:01.456 [ERROR] Update server connection failed. 2025-01-xx 10:23:01.789 [ERROR] Update server connection failed.一个明显的问题是日志系统没有做“去重”也没有设置“最多记录多少条”的限制。普通软件在发生重复错误时至少会合并同类日志或者做频率限制但 STM32CubeProgrammer 的更新器明显没有这个机制于是同一个报错被原封不动地反复写入。5.2 日志没有轮转机制正常情况下一个严肃的日志系统应该配套日志轮转设置单个文件大小上限、超过就滚动生成新文件、只保留最近 N 份文件。STM32CubeProgrammer 的这个更新器在当前版本里没有表现出这种行为。它在启动时以追加模式打开日志文件然后一直写到进程退出为止中间没有任何截断或滚动检查。这就是为什么问题一旦触发文件会变得非常大。你可以简单理解成一个水龙头被卡住了但排水口被堵死了水只会一直涨。5.3 为什么烧录功能不受影响很多朋友第一反应是这工具坏了要重装。实际上更新器和烧录功能是两个独立模块。烧录模块负责连接 ST-Link、加载固件、写入 Flash走的是一次完全不同的流程跟网络通信没有直接关系。因此不管日志如何失控你依然可以正常下载程序。这一点很关键意味着你可以放心处置更新器而不用担心耽误实际开发工作。6. 防止日志再次膨胀的日常维护技巧6.1 写一个定时清理脚本如果你不能改配置文件也不想更新器彻底瘫痪一个折中方案是用定时任务定期清理日志让它保持在很小的大小。macOS 上可以用launchd也可以用比较简单的crontab。crontab写起来很快crontab -e加入一行每小时截断一次日志0 * * * * : ~/Library/Logs/STMicroelectronics/STM32Cube/Updater_Gui_Log.txt这条命令的意思是每小时的第 0 分钟用冒号shell 内置空命令结合重定向符号把日志文件内容清空但保留文件本身。执行时不一定需要 root 权限因为文件在用户目录下。不过这个方案有个前提日志文件必须没有被更新器进程以某种方式“锁定”。大多数情况下:重定向是直接打开文件并截断即使进程在写也会让后面的内容从空文件开始继续写。实测下来没有出过问题但不够优雅。6.2 用 launchd 做更精细的清理macOS 下我更推荐launchd。在~/Library/LaunchAgents/下建一个 plist 文件比如com.local.cleanup-stm32-log.plist?xml version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keyLabel/key stringcom.local.cleanup-stm32-log/string keyProgramArguments/key array string/bin/bash/string string-c/string string: /Users/你的用户名/Library/Logs/STMicroelectronics/STM32Cube/Updater_Gui_Log.txt/string /array keyStartInterval/key integer3600/integer keyRunAtLoad/key true/ /dict /plist然后加载它launchctl load ~/Library/LaunchAgents/com.local.cleanup-stm32-log.plist这样每小时自动清理一次即使日志重新疯长最多只会占用一小时的量级基本不会对磁盘造成威胁。6.3 日志目录定期观察最后建议在日志目录上形成定期观察的习惯。macOS 下可以定期执行du -sh ~/Library/Logs/STMicroelectronics/STM32Cube/如果发现这个目录超过 100 MB就要检查一下是不是更新器又开始抽风了。日志目录正常情况下应该只有几百 KB 到几 MB异常时直接冲出几十 GB非常容易判断。7. 实测中容易踩的坑和常见误区7.1 误区一重装 STM32CubeProgrammer 就能解决很多人遇到日志爆炸后第一时间卸载重装结果装完还是老版本配置问题大概率复发。因为问题根源不在安装文件损坏而在于更新器与网络环境的交互逻辑。重装只会带来额外的环境配置成本解决不了本质问题。7.2 误区二删除日志文件就能释放磁盘如果你想释放空间当然可以删。但不要只删一次就完事。只要更新器进程还在跑它就会在删除后重建同名文件并继续写入。正确顺序是先退出进程再删除文件。如果不想修改任何配置可以等下个版本修复或者干脆用软链法一劳永逸。7.3 误区三更新器禁用后无法手动升级工具更新器只是一个便捷入口禁用它的可执行文件后你依然可以从官方网站下载新版本的安装包手动覆盖安装。所以它不会阻断升级路径顶多是少了一个“在界面里一键检查更新”的按钮。7.4 常见问题速查表问题原因建议处理方式日志文件几天内涨到几十 GB更新器反复重试并无限写日志恢复网络默认配置或禁用更新器删掉日志后它又自动重建更新器进程还在运行先退出主程序再删文件重启工具后日志再次快速增长自动更新检查仍然开启关闭 GUI 选项或修改配置文件更新器被禁用后提示找不到组件可执行文件被改名这是预期效果烧录功能不受影响软链到 /dev/null 后日志永久为 0写入数据被系统丢弃正常不影响其他功能7.5 我实际处理这个问题的顺序如果你也遇到了同样的情况我建议照着下面这个顺序操作降低折腾成本先用du和ls -lh确认Updater_Gui_Log.txt的大小用lsof确认写入进程退出 STM32CubeProgrammer把当前日志文件直接删除释放磁盘空间执行软链到/dev/null避免后续再次写入进入配置目录把自动更新检查关闭重新启动工具确认日志不再增长这套流程操作下来几分钟就能解决不需要卸载重装也不会影响你的开发和烧录工作。最后再分享一个小技巧如果你工作环境里的网络配置确实常年是特殊形态建议把更新器禁用后再手动设置一个每月一次的提醒去官网检查新版本。这样既避免了日志爆炸也不会错过工具更新。这比每次被磁盘写满再头疼要好得多。