让不让不重要，不要并排就好了。只要不并排有超车空间，对我来说就不算挡路，人家有路线可超车走人就 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==

这两个程序上通信上倒是好解决，主要是切换那部分的器件
第一个如果有合适的可耐酸的电磁阀那比较简单，但似乎并不好找。另一个想法就是使用电机的方式，然后每个通道做一个类似门之类的结构然后通过电机来控制开闭的方式（自然材料上是要可耐酸这样，这个结构可能并不太好设计）
第二个这个探头切换要看那个探头和 PH 计是如何连接的？如果只是电路上的连接那应该相对简单，像 CB4052 类似的芯片可以直接一边连 PH 计，另一边连几个探头的电路接口，通过软件控制芯片来选择连通某一路；如果在连接上有其他特殊的话那要根据具体情况来看这个切换的部分应该如何设计了

@snw 的确，而且 & 操作符也就是我想寻求的东西。因为 CONCANTENATE 已被官方标记过时，所以我觉得应该还是有方法可以达到同样目的但我不清楚；至于使用 CONCANTENATE 可以我也猜测到我只是刚好利用了一个可能设计原意并不是这样使用的特性，毕竟替代版的 CONCAT 的行为并非如此。

数组方面其实倒是没执念，只是好奇对于一个过时函数实现的功能，按兼容性为王的微软应该是有一般方法可以做到的，但找不到就还是很好奇如何做才能是符合设计理念来使用。在这里例子中固然是没必要使用 MAP+LAMBDA 来显示实现数组的操作，但还是很开心了解到了这种方法，后续使用说不定会使用上。

关于这两个函数的解释真的非常感谢可以一下子命中我所好奇了解的地方，看完我也的确更明白了。本身也是写程序的我对这个非常好奇，但又的确工作中使用较少导致对 Excel 了解甚少，只是抱着好奇之心来寻求一下答案，能够得到一个从原理上解释的答案真的非常满足。
再次感谢~

@crashdada 这个写法我明白了，其实就是将 CHAR(34)连接的运算放在 FILTER 的输出参数中先进行运算再输出。这样的确可以，其实这里也暗含了 & 这个操作符就是我想寻找的替代 CONCATENATE 运算结果的方法。不过后面 3 楼给出的答案算是完全解释比较明白，而且方案是一致的。这里还是非常感谢