只要电池是有标出 Wh 这个单位的，你都可以要求它按法规给你过。20000mAh 严格上来说并不是一个容量单位，还是要配上一个电压才能表明这个电池究竟有多大容量；一般所说的 20000mAh 只是 100Wh 按 5V 来计算得到的，只能说是没有表明 Wh 这个单位时的一个下位替代判断方法

以前我是很支持的，但现在我只能说各有场景吧。特别最近用了手表之后，手表弹个二维码给商户扫感觉更方便（其实手表也有 NFC ，但奈何和手机不是同一品牌没对应应用开不了）
以前有段时间很支持 NFC 包括用银联的 QuickPass ，但实际使用发现就是经过培训会选择用这个方式收款的员工其实真的是很少数，很多时间我支持但反而是商户员工不支持导致无奈放弃

的确要看智驾定义是什么，以及我认为以后是发展到 L3 甚至 L5 级别的辅助驾驶责任抛给了车厂我也是不会完全放任的，随时接管作为后备是我作为司机所应该的。按具体功能来说说我的情况：本田的非全速域 ACC+LCC+主动刹车，其中
1. ACC 一般是高速少车的时候才使用，因为我风格多变但不喜急刹，而 ACC 有一个问题是前面有一辆车突然变道插进来导致跟车距离不足就会急刹，这种情况我一般是预料到就会接管松油补一点点刹车避免急刹这样。
2. LCC 车道保持是常开，非全速域反而挺开心的，低速段我不用频繁关闭（因为低速段可能是在市区或者窄路但车道线还是有的情况，或者双向两车道中间虚线少车的情况，这种情况轻微压线开是很正常的。车道保持居中我觉得是极大程度让我可以放轻松的地方，特别是高速基本扶着方向盘，由 L2 系统来自动微调方向就很好了，不用以前开其他车时我要一直集中精神去左右后视镜不断确认是否会偏离得厉害来修正（毕竟高速的时候方向打一点就很容易偏很多）。另外尝试过在雨下很大的时候，快速路上的线我未必看清但 L2 自身可判断得清楚帮我稳住方向这点很好。
3. 主动刹车是常开的，但使用它的时候我觉得是你意识上不能说就依赖它，而是它作为我的一个后备辅助罢了。
至于现在很多智驾的其他功能，我是抱着积极拥抱尝试，但会比较小心选择是否接受长期使用。像自动变道这种，我觉得作用不大；你要说敢不敢我当然敢，但前提也是我会随时考虑接管而不是说就敢让这个系统去完成这个功能；另一方面自动变道、自动超车我觉得比较没太大作用，变道和超车考虑因素比较多我暂时还并不认为这些系统能做得比我好（个人主观意见），自动泊车这类我倒是觉得没太大问题，只要说这种场景由低速还出事车企能负责就完事了。

总之你要我完全交给系统任由它来控制我是觉得不 ok 的，但我抱着我随时接管我是那个 backup 的话那这些功能其实我都敢用

让不让不重要，不要并排就好了。只要不并排有超车空间，对我来说就不算挡路，人家有路线可超车走人就 ok

如果你的距离能一直被其他车插进来（不是超过你）的话，那我可能也觉得是你距离留大了，当然这个也不见得说是错的，毕竟安全距离留大一点对于自己行车是合理的但现实情况是可能自己开得不是那么舒坦。例如说插进来的车有一些很喜欢一插进来就刹车逼得你刹车。
我一般是有足够距离我就会变道超车，无论是否需要左穿右插，我只保证我变道时我观察它的车速我认为我能变过去和它保持 2 个车身距离以上我就会过。另外其实跟车的时候更倾向于你和前车是左右错开去观察前前车的车灯，用前前车的行为来预测前车行为的话其实一般并不会很容易导致追尾

今天路上竟然没想象中的塞车（甚至根本完全不塞车）

第一次见到楼主业务，恭喜楼主，做个分母

感觉看你自己的高频应用场景来设定就好了
我是经常看 log 要翻到文件的最前 or 最后所以映射成了 ctrl+home/end ，然后 dpi 键设定成了 win+L 离开工位一键锁屏 https://i.imgur.com/duWRpIu.png

简单来说问题是出在如上楼层所说的楼主你列的 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 被你刷掉了那这个中间商就没了，那自然在手上就和变砖了一样

@makaflow #12 第一个的话塑料的方案我感觉是挺好，但这个要看你后期的用量。主要是如果类似于公司的实验室那往往后期一直要用的话塑料直接开模之后后面成本是能降下来的，一次一抛的话完全没问题。至于你说金属结构件配合更换耐腐蚀易损件这个固然可以，主要是机械方面如何设计，方向上我觉得是考虑用电机来辅助推动某些机构来达到开闭的目的。
第二个的话既然是电路硬连接的话，接头的地方好处理，做个转接的就可以了。但这个不一定能直接接入树莓派引脚，还要看那个线路上的电压范围这样，可能需要一个辅助电路来配合。不过对于你说用树莓派来做的话，类似于 PH 计接到某几个 IO ，然后探头连接到其他 IO 这样的话，可能不太合适。我前面说的像 CB4052 的芯片就是有多个引脚，然后控制这个芯片是控制不同引脚之间的通断；而树莓派的不同 IO 口它本身是没法直接连一起的，那种适合是经过树莓派来做数据的控制处理之类的，但这里我看你 PH 计本身有其他软件来处理数据，你这里只是做一个通断选择就没那么合适。但可以用树莓派来控制 4052 这类芯片，搭建一个辅助电路（或者搞一块 stm32 的开发板其实也是 ok 的），树莓派用来接收 PC 的指令，对下控制 4052 来控制通断。不过其实我更倾向于直接上一块 stm32 会更轻量。
以上，我本身工作是做嵌入式的对 stm32 相对熟悉一点。你这种分路的场景其实我们的产品也有地方用到，类似于有多个温度传感器遍布仪器不同地方，然后接到同一个 AD 转换芯片这种，就会出现需要切换的场景。不过对于第一个那个切换我觉得主要在于结构设计，这方面我就不太熟悉了。如果有兴趣可以 vx 聊聊：d2hpdGVmYWJsZQ==