在技术支持群，看到客户报了一个不明原因的重启问题。重启现象是——有极个别设备在工作中不定时反复异常重启，大部分设备正常；反复重启设备，有时候又能持续正常工作。
隔着屏幕都感觉到了客户的着急和无奈，我决定和客户一起揪出这个“捣蛋鬼”。
一、查找线索
按常规流程先询问客户开发模块、开发方式，并要求提供对应日志。经确认如下：
开发模块：Air780E
最新资料：www.air780e.cn
开发方式：LuatOS
开发教程：
https://doc.openluat.com/wiki/26?wiki_page_id=3020
客户提供日志反馈：
脚本日志没报错误，就是不定时卡住一会，然后就重启了。
第一反应：不会是死循环导致的重启吧？
客户反馈：“没有死循环，任务里面都有延时的，而且大部分设备是正常的。且重启的时间也不定，最短4秒，最长是三分多钟，看起来不符合20秒的看门狗重启呀，而且设备昨天有正常工作一天，然后异常的时候就持续一直异常。但是这个固件的绝大部分设备是正常工作，不会异常重启的。”
看来不是死循环导致的看门狗重启问题。
为了进行一步排查重启原因，我让客户用pm.lastReson()这个接口打印开机原因值。
客户反馈：“我们有平台上传数据，pm.lastReson()是006异常重启”。
根据接口文档相关说明来看，确实不是内部看门狗导致的重启，是异常重启导致的。
接口文档详见：
https://wiki.luatos.com/api/pm.html#pm-lastreson
二、了解背景
心想看不出啥具体原因，先了解一下客户使用背景吧，说不定会有啥线索。
我问：“之前正常，现在是用不了，一直在重启吗？”
客户反馈：“也不是吧，一开始是好的，然后挂了几个月一直重启，最近发现，昨天我拿过来挂了一天又正常，然后今天又重启，老化区就这个设备会重启，其他同固件是正常的。”
我又问：“换DEMO会重启吗？确认一下是硬件问题，还是软件问题。”
客户反馈：“今天测试过，只下载脚本是一定会出问题。然后我刚刚重新下载底层和脚本，目前五分钟没有重启。”
看上去应该不是硬件问题，可能是软件引起的。心想让客户用最新版本试一下吧，确认一下还会不会出现问题。
客户反馈：“我们是因为有一个设备到客户手上有这个问题是V1108的，然后老化区只有这个设备也是异常重启，是V1106的，然后就看的这个，后面重新烧录1106的底层也是正常的，这设备挺难出现这个问题的，只能我们这边挂着测一下。”
看来又是一个令人头大的重启问题，要等客户提供底层日志来进一步排除问题了。
三、重要线索
客户把挂测的底层日志提供过来了，打开后确实看到了RamDumpData开头的死机信息。
打开上面的RamDumpData出现如下信息：
我赶紧和研发大佬确认，可能是啥情况。大佬问答大概率是FLASH坏掉了，让和客户确认不是有KV相关的操作。
客户回答，确实有KV的操作。
本文提到的KV：
KV数据库——指的是LuatOS中的FSKV库，提供键值对数据库功能，数据持久化在Flash上，使用独立的KV分区，使用LuaTools刷机时可选择清空，默认是不清空。由Flash的特性决定了，写入次数是有限的，频繁写入导致超限后，将无法设置/更新数据，导致系统异常。
为了进一步验证猜测，让客户做了如下测试：
问：“死机重启后，烧录不清除KV试试看还会不会重启，或者去除KV相关操作看还会不会重启。”
答：“KV操作挺多的，不好清除，我试下烧录不清除KV，有时候断电过一会就好了，不是很好复现，我先试试烧录不清除KV。”
客户反馈：“不清除KV也会有重启。”
问：“重新烧录底层的时候，有没有清理KV。”
答：“有”…
根据此前客户反馈和当前测试来看，应该是FALSH模块有些区域坏掉了。
四、确认猜测
至此，可以说这个重启的原因基本是确认了，导致模块令人琢磨不透的重启问题的“捣蛋鬼”也基础上算是给揪出来了。但是，还是需做进一步的测试来确定猜测。
研发大佬给了一下测试固件，来确认猜测是否正确。
经过测试验证后，确定是FALSH部分区域坏掉引起的重启。
至此这个“重启案件”算是侦破了。
给客户的建议：
要改脚本，需要大幅度减少写KV的次数，防止破坏模块重启的“捣蛋鬼”再次出来捣乱。
温馨提示：
KV的写寿命是10万次，过于频繁操作可能会导致FLASH坏掉，引起设备反复重启。
因此，在写代码的时候要尽量减少写KV的次数。