@konakona 不过在 Mac 上，Chrome 应该是用的 keychain 保存密码 /或者加密密码的，比 windows 上应该安全的多。windows 没有 keychain ，我也不懂如何有一个好用又安全的方案（除非你每次填密码之前都输一遍 master password ）

@o00o 有些问题是逻辑问题，并不可能造出永动机

@konakona 但是你有没有想过，Chrome 的密码必然是保存的原文，你打开 Chrome 填写密码之前也没有输过任何 master password ，离线也可以输入密码，所以可以完全还原你保存密码的所有信息必然全部保存在你的机器上。

这根本不需要被发现，是必然的啊。

Safari 安全的多，Safari 背后使用 keychain 保存密码，系统级地进行权限控制，所以你不可能写任何程序（除非出现安全漏洞）偷偷读到 Safari 保存的密码。并且每次输入密码前都需要进行指纹 /人脸认证，也就意味着密码不会明文储存在 Safari 中，也不会被任何其他程序通过任何方式冒充 Safari 获取。

@ltkun 只是加了 Google 同步的部分，其他逻辑都一样的。Google 也不可能给 Chrome 做的比 chromium 更安全。

@juejinloop 这大概就是安全的错觉吧。

从安全性的角度来说，不论 Chrome 做什么都是没有任何意义的。Chrome 的代码本身是开源的，密码储存逻辑必然是公开的，有心人不需要花太大精力研究就可以搞明白。只要 Chrome 的密码管理可以离线运作，那所有解密密码的信息必然全部存在本地。

如果软件没有恶意（我不能理解一个想要读你的密码的程序为什么你觉得不是病毒），那怎么做都没差。如果软件有恶意，那 Chrome 不论做什么这个软件都可以轻松根据 Chrome 的源码破解。

做出什么决定都可能是理性的选择，但是如果根据你的题干做出的任何决定都不可能是理性的选择。你压根就什么条件都没给，怎么可能会有任何一个理性的人会给你理性的选择？

出国呆过多久？留过多久的学？工作过几年？是否适应国外的生活？英语 /当地语言水平如何，社交能力如何？个人性格如何，能够适应什么样的环境？为什么不喜欢国内的环境？

别说不同国家了，就算是美国里面，硅谷和纽约能一个样么？去城市还是大农村？能找到什么级别的工作？能拿到什么签证？

以上只是无数需要考虑的问题里小小的一点点，你一个都没有提到，现在你说你要做理性的选择……

看了上面的回答，感觉现在润学已经魔怔了。

啥意思？开源的人都追求不用中文而是用国外开发者使用的母语（是指英文吧）？所以很幼稚？

后面又说开源是国内程序员想过国外程序员的生活？所以是开源配不上中国人啊还是中国人配不上开源啊……

完全没有看出其中的逻辑

这个时间点买房，而且只有三十几万，就算你所有的其他故事背景都不存在，我也是实在是不知道该说什么好了

每当这个时候我就特别能理解为什么说千万不要用新特性，没事不要修改不要更新不要升级了。这水平要是写 for 可能这代码还跑的快一点，至少不用 collect 这么多次。可读性本来就没有，所以也无所谓了。

@yiqiao 为什么开源就是 KPI 项目？ Google 内的 perf ，帮助整个公司 migrate off C++肯定比开源个没啥人用的语言要有 impact 的多的多的多的多。只是文化上 Google 就是很喜欢开放，能开源的东西基本都开源了。

但是明显这个只是顺带开源，没想着要有人用，也没人靠这种东西拿 OKR （可能万一做大了会有几个 developer advocate 的 role 吧）。Google 都已经说的这么明白了，我这东西是为了取代 C++，请大家去用 rust ，不要没事用这个项目，想拿 KPI 的人会说这个话么？

@junkun 因为目标就是 migrate off C++，兼容是过程，目标是干掉 C++。就如同 swift 可以调用 objective-c 并不是因为 apple 太爱 objective-c 一样。

Google 的内部项目顺带开源了而已，有没有人用根本无所谓，Google 自己把自己的那堆内部的 C++慢慢替换掉就行了。和 hack 一样。

@Tussik 线下必然能复现这个问题啊，就几行 lua 代码，我现在也能复现，不然如何定位到问题？但是能复现和可测试之间是没有任何关联的。

因为你不知道应该怎么测，测什么。

首先 unit test 是没有任何意义的，这个就不用说了。可能的基本只能是 integration test 或者 smoke test 。对于这类完全不 predictable 的 edge case ，smoke test 也基本没有任何意义。那么就只能做 integration test 。

integration test 这个天坑我也不想多说，做过的都明白，最后只能 test 基本的 case ，确保模块间正常可用，甚至不能测试真实日常场景，更不可能测试 edge case 。别的不说，你就想想一般 unit test 里都经常只测 happy path ，好一点的也一般只有 utility 才 coverage 100%，很多逻辑都无法测试。很多时候为了 coverage mock 来 mock 去最后基本都只是在测试 mock 写对了没有，业务逻辑都 mock 光了。现在你来说 integration test 还要测这么复杂的 edge case ？不可能的啊。

@eason1874 用更容易出错的方法来解决一个不太容易出错的问题么。这不是把小坑挖成地道了么。

@Tussik 测试什么呢？参数是系统外传入的，你根本就不知道外部会传入什么。

测试在这里其实是基本没啥用的，这也是为啥大公司的 RPC 都是强类型的，因为没有强类型这种问题完全无解。

在动态语言中，根本不可能对每一个方法都做大量 runtime 的类型检查，唯一能做的就是确保参数进来的时候就不会错。

@heyjei 对于这个问题好像没啥意义吧

google.cn 永远不可能显示 nginx 404 。Google 就不用 nginx 。

内向的定义如此模糊使得严格按字面讨论这个问题毫无意义。

不过考虑到很少看到有人需要努力找寻“外向”的意义，我猜这里的“内向”实在没啥正面的含义。大致就是日常工作中和同事几乎无社交，闷着一整天不说几句话；工作交流总是不顺畅，说不清楚也说不顺；汇报总是抓不到重点也没有气势；如同空气一般的存在。生活中不敢对喜欢的女生主动，甚至连和店员聊天砍价都不敢，没有几个聊得来的朋友，也没有玩伴，平时宅在家里也无处可去。

然后我们再把以上的这些特点都归结为，原来是因为“内向”，最后再来找“内向”的优点，未免也太荒唐了。以上就只是缺点而已，和“内向”无关。所以无论内向有什么优点，也不代表你具有这些缺点之后就具有了那些优点。

自己给自己贴上“内向”标签不会拯救你的生活。要是对自己的缺点不满意，要么改变，要么和解，不敢改变又无法和自己的缺点和解，显然和楼上某些说的“能够向自己的内心获取力量和价值”差的也太远了一点。