启动就重启：
一个数据库的跨平台尸体

先走错的那条路：网络

第一反应是网络。这台机器所在的网络环境，访问若干海外服务本来就不通， 而「加载不了设置」听起来特别像「连接不上服务器」。于是我查了解析、试了代理、 看了连接状态——都很正常，问题照旧。

这一段最大的价值是它教我的：症状的措辞会骗人。 「加载设置失败」这个说法，既可能是网络，也可能是本地文件；而我先选了听起来最像的那个。

转折点：去看日志，然后手工跑一遍它要我做的事

日志里有两条反复出现的记录：一条说读取启动策略失败，另一条说等待策略就绪， 超时时间正好是三十分钟的五分之一——也就是那五分钟。两条拼起来， 「等五分钟重启」这个古怪的时间常数就解释通了：读不到策略，等一会儿，重启，再来。

日志里还能看到：应用启动时会拉起它自带的一个后台内核进程。 我把那条命令手工跑了一遍——立刻拿到了真正的错误，一句话： 无法在配置目录里初始化本地数据库。

三个实验，一次只动一个变量

拿到方向之后，事情就变成解题了。我做了三次实验，每次只改一样东西：

第三个实验是最有意思的：它排除了「文件损坏」这个解释，剩下的就只能是 跨平台/跨版本的格式不兼容。也就是这一层数据只对生成它的那台机器负责。

校准自己：别用「日志里红字最多」当判据

排查过程中我差点被另一件事带偏。旧机器的日志里，同类的网络报错有六千多条， 而旧机器上一切正常。所以这类报警根本不是故障源——它是环境噪音。

这件事值得单独记一行：出现频率高不等于因果关系。 如果一个现象在「好」的机器上也大量存在，它就不能解释「坏」。

修法：备份、重建，然后只拿回该拿的东西

修起来其实很轻：把整个配置目录改名备份（不删，先留着），新建一个干净的， 然后把配置文件和真正需要的子目录拷回来。

关键是什么不要拷回来：

重启之后按之前定的标准核对：日志里那条「读取启动策略失败」的计数应该是零， 并且出现一行表示应用路由已经挂载成功的记录。两条都对，才叫修好了。