@fuyun 说明目前你还不是 OP 的读者用户群体

@soul11201 原文：一切言动，都要安详。十差九错，只为慌张。 - 小儿语

只要不犯大错就可以，与你协作的这个网络，就会兜住底。不然的话，公司只要你一个人不就可以了吗~

上面那段话，前端时间教孩子度《中华优秀文化选本》的时候现学的，一本明代蒙学启蒙书上的。

@sagaxu https://data.stats.gov.cn/easyquery.htm?cn=E0103 稳中向好，歌舞升平

“十差九错，只为慌张。”

才 25 岁，这么年轻，主要是目前大环境确实不咋地~

居然还能这样

换个思路看下这个问题：调用栈比较深的时候，是否强制程序员显示处理流程异常终止情况。

1. PHP 是不强制的，在调用处看不出来处理程序可能出错。如果不 Catch 一个 Exception 的基类，可能导致异常漏处理;;但是写的很多，代码就很啰嗦、过度防御 。两个方面不管从哪个角度来说，都是工程质量堪忧。

2. Go err 最佳实践，其实就是强制显示处理错误，调用处就能看出来程序可能处理错误，整体看上去就是做 err 体操，有些呆板。

3. Java Exception 的 Checked Exception 和 Runtime Exception 设计思路，分别是 Go err 体操路子和 PHP 的埋雷路子。Checked Exception 相比 err 体操只不过是标记在了方法签名处，看上去代码少写了两行，但 Checked Excption 是从哪里丢出来的就不太明确了。从 Checked Exception 的实际使用情况来看，偏 Runtime Exception 方向倾斜，就是逐层标记不处理的多，垃圾~

从设计和实际使用综合来看，还是 Go Err 相对来说更严谨一点

不要想的这么复杂。
1. 用电脑把数据定期手动备份到一个移动硬盘
2. 防止硬盘损坏，定期更换移动硬盘，或者一开始就买两块移动硬盘。
3. 多设备同步、方便存取的话，再同步到云盘。

个人觉的最重要的还是定期备份数据，定期备份数据这个流程自己也要弄的足够简单，另外还要防备份的时候出现不一致性。

是的，和基线对比

推荐 OP 看下 Camunda 这一套工具，
软件作者还写了一本书《流程自动化实战：系统架构和软件开发视角》，中译本我读着的时候有点费劲，可能翻译的问题，建议读一读。

@rubbishmod 理解你说的了，没有业务流程设计相关的挑战，那这样写确实非常好了。

@karnaugh 换个词，用形式化的方法支撑复杂多变的业务逻辑。项目工程上想做到规模化支撑，不知道还有没有比这个更好的方法。

微保，少儿百万医疗险