先说一个我在做推荐系统 AB 实验架构时观察到的现象。

某个业务团队跑了一个月的实验，结论是新的推荐策略效果显著，CTR 提升了 12%，上线。三个月后回头看，整体转化率没变——用户只是提前点了，没有多买。没人复盘这件事，因为所有人都已经在那个"12% CTR 提升"的实验报告上签了字。

这不是个例。在金融产品场景里，我见过太多 AB 实验的结果被当作结论使用，而实验本身的设计、指标选择、对照组偏差，几乎没人认真审视。大家需要的不是真相，是一个可以写进周报的数字。

数据驱动这个词已经被用烂了

每家公司都说自己是数据驱动的。但如果你仔细看他们做决策的过程，会发现一个很典型的模式：先有结论，再做实验。

产品经理已经有了想法，设计已经出了方案，开发已经排了迭代——实验只是最后的"验证"。注意，不是"验证假设"，是"验证决策"。这两者有本质区别。验证假设的时候你真心想知道答案，验证决策的时候你只想要一个通过。

这种心态不是某个人有问题，是整个系统的激励结构决定的。一个做了三个月的项目，谁愿意在最后一步承认实验结果不支持上线？于是你会看到各种"实验结果不显著但趋势向好"、"主要指标未达显著但次要指标表现优异"的结论。翻译成人话就是：实验没通过，但我们还是要上。

打开任何一个前端项目，全局搜索 `catch`，你会看到什么？一大片空荡荡的 catch 块，偶尔跳出几个 `console.error`，再偶尔冒出一行 `message.error('系统异常')`。后端项目也好不到哪去，try-catch 包着业务逻辑，catch 里面的处理方式跟前端如出一辙——记个日志，打个错误码，然后呢？然后什么都没有。

我把这种写法叫"安慰剂错误处理"。它的作用不是解决问题，而是让写代码的人觉得自己处理了问题。就好像感冒的时候吃维C，你做了点什么，但那点什么跟治愈没有关系。

更残酷的事实是：大部分错误处理非但没用，还在制造新的问题。

try-catch 不是错误处理，是错误藏匿

先说一个很多人不愿意承认的事：try-catch 是所有错误处理手段里最廉价的那一种。它的成本最低，所以它的价值也最低。

我见过太多这种代码：一个函数内部包了三层 try-catch，每一层都把异常吞掉，最外层返回一个 `{ success: false, message: '操作失败' }`。调用方拿到这个返回值，判断 `success` 为 false，然后弹个 toast —— "操作失败"。用户看到这四个字，内心毫无波澜，因为他已经见过一千次了。

安装2012版的手机QQ之后一直不停的提示群消息，烦死了。

找了半天才发现原来设置在“群资料”里。步骤：

1. 登录手机QQ
2. 切到群组里
3. 打开你不想接受消息的群
4. 然后按设置菜单键-> 群资料
5. 关闭接受群消息

转自：http://hi.baidu.com/wlj1013/item/3e6080351168b9302f0f815c

一 相关下载

(1) java JDK下载: