whitefable

简单来说问题是出在如上楼层所说的楼主你列的 4 种情况不是等概率的。展开说说其实是选手选择和主持人选择本身是分两个步骤，且非独立事件（主持人如何开还是依赖于选手选择的事件），这两个事件的总体概率计算如#10 所描述是合理的，楼主所谓的列出是隐含了 4 种情况均为 25%的概率所以不太对。
其实我觉得有另一个很简易的想法是：P(换了中奖)+P(不换中奖)=100%。那这里显然计算 P(不换中奖)是比较容易的，即只取决于第一次选手的选择，那就是 1/3 概率可中奖；那此时 P(换了中奖)的概率自然就是 2/3

@leaveeel 楼主的确可以试试 84 楼的方法可破。之前我老婆去建行开工资卡也是各种限制啥的，然后办了信用卡之后银行直接主动帮你提升储蓄卡限额以及各种限制。

感谢楼主，最近我也发现我的卡经常性网络时不时会断流一样，但另一张 sim 卡就还好。你这么一说我这张卡好像也很多年了，这就去换了试试

@FatSheep2020 #6 是的，多个任务就多个文件夹，每个文件夹都是等同于项目全量备份。其实这么做和在 svn 服务器上拉一条新的分支区别在于：
a) 如此做法只是在本地将两个开发分开，但实际的提交历史还是同一条，且 A 提交完后 B 再提交前必须要先强制将 svn 服务器上的新的提交都 update 到本地才能提交（其实也等同于一次合并过程）。但服务器上不用说改了任务 A 一部分，后续还要记得将变更 merge 到任务 B 这里，毕竟提交都是在同一条线上的
b) 服务器上拉分支就是服务器上先给你全量 copy 一份项目，然后将两个提交分开在 2 条线上而已。这么做的话可以令 AB 在开发过程中怎么提交都 OK ，可以保留更多的细节（相当于 a 在同一条线上提交可能就会不提交太细节了避免太多多余信息），最终再进行合并。这种做法和 git 大概有点类似？但我一直也没找到什么好方法可以很好在 svn 的线性提交历史里面找到正确的合并点

说到 b)中的合并点也不得不说 svn 的 merge 和 git 还是有点区别的。git 的合并总是会强制自动产生一个提交；而 svn 的合并并不会，本质上来说 svn 的 merge 只是很简单的将另一个分支上你所选择的提交所记录的变动直接应用在本地文件夹，本身就是基于文件/文件夹操作的，所以在提交的 log 里面是记录着哪些提交被合并了，而不是像 git 一样是一个单一的合并点。另一个核心点在于 svn 的提交记录是必须线性的，所以你可以看到有一个全局 svn 号，可以直接唯一定位到哪次提交；而 git 本身就是非线性的，从而对于多分支做法有自身的优势； svn 的线性意味着你要像 git 一样去理解操作的时候，其实最终提交到 svn 服务器上都会有一个类似于 git 中的 rebase 的操作 => 将分支的变更需要将原来分支点转成基于当前最新提交作为分支点再进行提交，从而线性化。

只能说 svn 和 git 其实底层是有一些逻辑不太一样吧，反正怎么舒服怎么来。我现在做法一般是本地可能扔一个 git ，用来维护日常的变动甚至非常小的变动，从而使得新版本在机器上万一改出问题比较好回退，同时 svn 上不会产生特别大量的信息。对于上述 a) b)两种情况其实我这里也是有混用的，一般例如说如果是机器硬件产生比较底层的变化，但大体上逻辑是一致的，那需要维护两个版本则我们会用 b)从服务器直接拉分支，并且更改时总是基于一条分支做主要变更，另一条分支不断用 merge 将变更同步过去就是了；而一般临时性或短期性的多个需求点的开发则会采用 a)这种方式，一个需求点搞完了本地这个文件夹就可以扔掉直接清理掉不管了。

说了这么多就顺便说到另一个问题就是像你正在开发任务 A ，但又有一个 bug 要改的 hotfix B 。在 git 里面也是直接拉分支比较方便的，但 svn 我倒是遇到一个问题在于 A 已经提交一部分了，这时候改 B 就不可避免在提交历史上 A 和 B 是穿插的。所以这里 svn 其实本身也提供了另一种工作流：项目一开始就建立发布分支和开发分支（当然还可以再建立多一个 hotfix 分支）。然后开发分支上做开发工作，这时候 hotfix 修复 bug 的话其实你提交在开发分支也没关系。基于 svn 的 merge ，那你需要 review 其实是发布分支，当你完成一部分功能或者修复了一个 bug 直接只需要将需要的提交挑选出来，直接 merge 到发布分支就完事了。这也是一种方法

其实 svn 也有 shelve 功能但的确不太好用，而且事实上我这边也有类似的问题，虽然我司没那么严格的 review 机制。方法也是有的，我这边有 2 种做法吧：
1. A 、B 任务同时开发，那提交记录必然是两者有互相交错；那就在 review A 之前将所有 B 的提交都 revert ，而将 B 加回来也很简单，前面那次 revert 之后会产生一次提交，只需要将这次提交再 revert 一次就 ok 了，这么做就是来回比较麻烦而且提交记录上有比较多这种 revert 再 revert 的记录
2. svn 的分支给我感觉上相比 git 的确是没那么好，但也有适合于 svn 的方式。那就是你在本地开发的时候，假设 svn 当前 head 的版本号在 1000 ，那就任务 A 和任务 B 分别建立两个不同的文件夹都 checkout 1000 这个版本（并不是开新的分支），然后在这两个文件夹内开发。这么做的缺点就是每个任务开发过程中就不好提交了，不然就和 1 其实是类似的，提交记录总是一堆交错。一个折中的方法是文件夹内可以自己用 git 本地管理，然后差不多了再提交一波大的到公司的 svn 去，这样子记录相对干净一点。
其实基于 2 当然也可以用分支的方式，分支的话 A 提交了啥到时候直接将相应提交 merge 到 B 即可。不过 svn 的分支+合并并不像 git 那么清晰；之前也和领导讨论过 svn 的分支比较舒服就是本地直接搞多个文件夹，然后文件夹内开发就是了

@ahdung #44 emmc 是通用存储设备，和 PC 硬盘的确是可以类似的。你所说的也没错，只不过硬盘的接线比较简单，大部分人都可以直接将线拔下就换到另一套环境中。而手机中的 emmc 基本都是贴片方式焊接上去的，所以想拿下来挂接的话可能大部分人都没这个动手操作能力，但如果有的话（一般还需要有热风枪、焊枪等设备，例如手机维修店可能就能具备这些设备和能力），完全可以做到你说的拿到另一套还原之后再焊接回去。
至于你说最后一个不用抠下来，直接接触引脚这种情况，分两个情况考虑：
1) 主板上有单独的接口可以有机会通过 CPU 再访问到这个芯片或者另外的接口可以访问到这个芯片，那只需要用相关设备接入到这个接口再遵循通信协议来将数据传输过去就可以
2) 直接将相应的电线接触到引脚上来完成电气连接，从而挂接到另一套环境进行恢复。这个情况我只能说理论上可行，但实际基本不可行。原因在于这种连接方式不稳固而且有极多的杂波，这将会影响数据传输时的时序，使得传输过程基本不能完成，所以实际操作上是不太可行的；实际上按 1)中将芯片吹下来再拿到另一套环境来进行恢复是可行的，但大部分人不具有相关工具和能力（所以说变砖了），同时可能大部分维修店出于成本和利润考虑似乎也不太愿意做这种事情，除非你数据非常重要要挽救之类的付出足够多的金钱（芯片搞下来也可以用于挽救里面的数据这类）

其实 4 楼和 12 楼的意思差不多了，问题在于你如何能够轻松将备份恢复到 EMMC 呢？
启动过程大概是上电后 CPU 从固定区域读取数据（如 PC 的 BIOS 区域，Android 的 Recovery 也是存放在 EMMC 的固定区域） -> 然后运行 BIOS/Recovery 去引导系统 -> 系统启动。刷机的时候如果将 Recovery 刷挂了，那意味着你手机上电之后 CPU 没有程序可以加载，那么这时候就没有办法接收你备份的 EMMC 数据再写入恢复。所以这时候一般需要用到编程器（可以将 EMMC 拆下来，或者如果电路板上有编程器用的接口也可以），编程器其实也是通过另一种启动模式令到上电时 CPU 直接从编程器加载所需要的程序，这样子 CPU 有一段程序之后自然可以接收 EMMC 的数据进行刷写。
一般所说的变砖只是无法在不拆下 EMMC 的情况下进行恢复，编程器一般还是和芯片强相关的，一般也不容易获取到或者日常中作用不大。所以你要说先备份就永远不会变砖就也对也不对吧。存储芯片你想要恢复回去数据肯定是有办法的，但在于接收你的备份数据并写入到存储芯片这一中间的部分是否可以轻松完成罢了。所以说充当这个角色的 Recovery 被你刷掉了那这个中间商就没了，那自然在手上就和变砖了一样