概率性问题解决思路
嵌入式软件的开发人员多多少少被概率性触发的bug折磨过，我也是饱受其苦，本文想要介绍一些解决这类问题的思路，主要是方法论，实际的调试方法可能不会过多涉及。
在讨论之前，先引入一个概念：在我的理解里面，嵌入式软件开发过程中，bug 可能出现在不同的层面。这里暂且分为以下三类：
- 嵌入式软件工程师应用代码的bug。一个不争的事实是，大多做嵌入式软件开发的工程多是电子信息工程专业毕业，这类工程师在学生阶段没有接受到太多的CS知识，自己的主观学习意愿也不强，对于数据结构，计算机原理，编译原理一知半解。写出来的代码不说漏洞百出吧，说四面漏风也不为过。特别是一些做消费级产品的小公司，可能就只有一两个嵌入式软件，完成功能后没有做系统性的测试。大公司大平台的嵌入式软件工程师的水平也不见多好，但好在公司流程规范，测试流程完善。之前看到嵌入式的论坛上面有人自嘲，嵌软只会写while和if。这当然有些夸张了。总之，嵌入式开发过程中九成的 bug，其实都源自开发者自己的代码问题——要么是操作步骤不对，要么是细节处理不到位
- 官方提供的软件包（SDK）中的bug。这种情况当然也是存在的，毕竟SDK的代码也是人写出来的，出现bug也是难免的。我想那些国际MCU大厂没也法保证自己的SDK库文件100%没问题。现在嵌入式开发大多都是使用的官方SDK里面库函数，里面封装的寄存器操作可能很多开发人员都不会去看。但是如果在调试过程中确实出现了bug，也需要对底层库表示怀疑，不能认为它是一个完全的正确项。对UM手册的内容有些也不能奉为圭臬，毕竟近几年国产MCU雨后春笋般冒出来，各家原厂间的水平参差不齐。
- 芯片本身的bug.这种情况事实上极少，但是也确实存在，勘误手册这个时候就非常重要了。当拿到一个新系列的芯片时，在开发之前有必要先对勘误手册大概浏览下，提前了解能有效避免踩坑。大多勘误手册里面还会提到规避方法。
找到稳定复现问题的方法
所谓“出现没有规律”，并不是说问题在客观上真的毫无规律，而是开发人员尚未找到它的触发规律。有时自嘲说是“玄学”问题，更多的时候是自己技不如人。
一般来说系统中总存在某种条件会引发异常，例如：
- 执行了某个特定操作；
- 与外部设备通讯时触发；
- 运行到某个特定函数；
- 新增某项功能后才开始出现问题。
通过对比、回溯和排查，我们可以根据结果反推原因，从而找到问题的“临界点”。
这是整个调试流程中最关键的一步。
只有先找到能稳定触发异常的方法，后续的分析和修改才有意义。
否则，所有尝试都只是空中楼阁，根本无法判断问题是否真正解决。
对于这类概率性问题，不能凭“系统平稳运行了多久”来判断修复是否有效。
即使系统连续运行一个月没有出错，也并不意味着问题消失了——
它完全可能在第二个月、第二千次触发时再次出现。
因此，验证修复的唯一标准是：问题能被稳定复现、再通过修改彻底消失。
在可复现的基础上进行验证与闭环
当你已经找到稳定复现的步骤后，后续的修复往往会变得水到渠成。有些时候解决方法可以拍脑袋想出来，只要最后问题能解决，逻辑能自洽也是能接受的
比如，假设你发现程序总是在与某个外部设备通信时触发 bug，
那么可以尝试将这部分通信代码从整个工程中独立出来，构造一个最小复现场景，
再在这个简化环境下逐步验证、定位和修复。
当你找到解决方法后，务必再次经过完整的验证流程：
触发 bug → 复现问题 → 应用修复 → 再次复现验证 bug 消失。
只有经过这一套闭环验证，问题才能算真正解决。