我觉得高德的产品经理考虑的用户群不是司机

但百度一定是考虑过司机的


百度的语音真的比高德好懂很多，去陌生的地方找了条断头路不是最抓狂的，而是前面的标线你本来看懂了导航一忽悠给你整不会了。

百度就从来没给我整不会过，高德那是得脑子里多开一个线程专门翻译它想表达什么的程度

1. 接口信息是不应该怕泄露的，有很多业务甚至为了方便自动化会主动把接口暴露并提供规范的使用方法
2. 鉴权和 csrf token 之类的东西早都已经纳入各种框架中了，都可以拿起来就用，不用担心实现难度
3. 前端的 distribution 版 js 都是压缩混淆过的东西，一般人可看不懂，甚至就算不压缩混淆，框架的源码复杂度已经足以令人发指了

2002 年： 卧槽我放照片的硬盘坏了！未来要是能把数据全托管到服务器是不是就不会丢失了
2022 年： 卧槽云相册空间又收紧了！未来要是能把数据都存在本地是不是就不会受制于人了


其实我刚看到还以为是个宽泛的个人资产管理，小到我买了多少东西记得收快递大到房产贷款单放在哪个抽屉都能结构化地分类存放方便搜索记忆。这种需求应该还挺普遍的。

但数字资产…… 你真的很难做出一个 用起来比「把用户密码地址复制粘贴到 note 上」更方便简单的东西。

我的上上上部手机里有个笔记，存了我 10 多个小号的 id 密码密保问题
我的上台工作电脑里存了 10 多个公司各种服务器的地址
我现在在用的电脑里还存着 7 8 个 ssh 公钥私钥文件



但上面的东西已经全都用不着了


做产品真的挺讲究「讲好故事」，看起来 OP 的故事就讲得不太好

想了一下
如果不是个 dating 产品，那它应该是个结伴产品，比如有些存在风险的活动，登山、滑雪、潜水什么的，没有朋友一起来，匹配个陌生人起码也能获得基本的照应。这种结伴需求的联系是非常浅的，滑雪每趟我都希望能有个人在后面看着免得我伤了都没人知道；但这人是谁没所谓，是同一个人也没所谓


不知道我想的场景是否符合。

别头铁，北京是真进不来，别说出发地劝返，你进了北京地界也能给你弄回去……

1. 你没有从公司复制源码，因此这个方向上不构成侵权
2. 如果你不去模仿公司申请了著作权和专利的外观设计、系统组成、特殊机制，那么这个方向也不构成侵权。但注意了，前提是你知道哪些地方是专利并且真的绕开了
3. 不构成侵权代表如果被起诉，你有能打赢的依据，但不代表对方不会起诉你
4. 如果你没盈利也构不成竞争，一般不管你什么，最多 HR 黑名单（

@Protocol 看来 OP 的作品确实不咋样，被你一本正经地指出来了

------

只能说，弱智吧混得不够多

OP 看到浏览器登录时 post 了它的密码明文时不得吓得几晚上睡不着……

在加密信道中传输的内容怎么算「明文」，你的系统输入框还「明文捕捉」了你的密码输入不是

@0o0O0o0O0o 你没抢到一楼真太可惜了

随手一搜： https://www.cnblogs.com/yinkw/p/redis_keys.html

在 kv db 里全文扫描是否搞错了什么？ 这样还不如 sqlite :memory: 呢

@cssk 电脑效果也不好，因为微信会一直有大量的消息提示弹窗，总不能设置 @才提醒吧

我试过在写代码有消息 4 个小时都没看到，不是我没去看，是每次划过去没看到红点就划回来了，4 小时候仔细一看卧槽怎么已读了

@iceheart c++中字符类型和整型是同一种类型：

'1'+1 => （这里的类型应该是？）

你说的不就是 kindle 嘛 :doge:

1. 绝大多数的泄密的原因都在用户身上，比如单一密码、存储不当、被钓鱼。 你想想对于访问者来说，密码用于加密文件本身还是用来防止访问文件有什么区别吗？
2. 在今天，绝大多数网站的 ACL 核心机制已经不是密码了，而是——手机短信。
3. 加密文件成本又高，还把更多服务方向给断绝了。我传网盘本来就是为了省空间，然后传上去所有文件还不能在线观看，意思是存照片视频文档这些文件的用户需求全都不管了，只管那些有保密需求的？
4. 你有没有下过一些「找了半天发现没有密码」的神秘小资源？——他们有个特点，要么谁都没密码，要么谁都有。

@zhaol 在他的 feture 合并前，应该准备好 4 个分支：1 你的 feature ，2 他的 feature ，4 有他 feature 的版本分支，4 没有他 feature 的版本分支

我们之前的实践是，有一个接受所有 feature 的分支，比如 master ，然后给每个要发布的版本建 release 分支，他先写完后合并到 master ，你写完，rebase master ，合并。此时 master 上有两个 feature （ 0-2-1 ），而 release 上还什么都没有。 像 gitlab 有 自动 cherry-pick 的功能，web 界面上点一下可以把整个 MR （比如你合并 master 那个 MR ）里的所有 commit 都 cherry-pick 到另一个分支上（ release ）。pick 完 release 看起来像是（ 0-1 ），但 1 的那些 commit 不是原始 commit ，是 cherry-pick 重新生成的。

如果 web 界面没有这个功能，就只能在本地手动 pick 一堆 commit 。不过鉴于 release 分支一般也不需要保留修改历史（ master 已经有了），所以可以把 feature 的所有 commit 都 squash 成一个 pick 给 release ，这样手动也不会很麻烦

@cyang812 rebase 后分岔点在基分支的最前端，merge 的分岔点是基分支上历史中的某个点。rebase 的历史永远是线性的，merge 会织出复杂的演化网。

rebase 目标分支和本分支不对等，你基本不可能搞错（不可能试图把 main 拼到 feature 上，只会把 feature 拼到 main ）
而 merge 就可 tm 难说了，feature merge main 和 main merge feature 观感上根本没什么区别，看起来也都很合法，但形成的历史网是不同的，出问题的时候根本没人有能力搞清楚发生了啥

其实没有「远端解决冲突」一说，所有的合并和冲突解决都是在叶子节点上或者说都在 git 的「客户端」进行的。

web 界面只是自动做了一些额外的事情而已，跟你在本地用一个 GUI git 工具是一回事。




> 当我的 feature 开发完毕后,origin/main 可能已经更新了很多个 commit(从其他 feature 合并而来),很可能存在冲突

此时你 **不应该进行任何 MERGE 尝试**。

1. 首先应该在本地切换到主分支（ dev/main/master ），拉取远程的状态。由于你不可能直接在这些分支上修改，所以这一步不会产生任何冲突，仅仅是快进
2. 切回到你的开发分支，把它 rebase 到主分支上，此时产生冲突，resolve ，重新 commit 。
3. 由于到目前为止你还是只修改过你的独占分支（就算有远程也是可以随便 push -f 的那个），所以不会对其他人产生任何影响。
4. push 你 rebase 过后的分支，开启或刷新 MR





之所以采用不断 rebase 分岔点的方式是因为，如果你不进行 rebase ，merge 操作时是一个三路合并，而三路合并是一个**既复杂又存在危险性** 的操作


(!!) 其实我本来想简单解释一下为什么三路合并会出问题，但在我搜索看了近一个小时文章后，我选择放弃解释：
https://www.waynerv.com/posts/git-merge-intro/
https://git-repo.info/zh_cn/2020/03/something-about-git-merge/
https://actake.github.io/2021/03/21/git%E5%BF%85%E7%9F%A5%E5%BF%85%E4%BC%9A-%E5%88%86%E6%94%AF%E5%90%88%E5%B9%B6%E9%82%A3%E4%BA%9B%E4%BA%8B/





(!!) 因为这已经是我至少第 4 次搜索这个问题然后仍然没有完全搞懂了


如果采用 rebase - merge FF 的方式，合并操作等同于在对方分支上把你做过的操作重放一次，心智负担和风险要小得多。只有一个麻烦，因为是重放，当你的 commit 序列一开始就与对方冲突时，这个冲突会有传递性（对方是 A ，你第一个提交把 A 改成了 B ，后面的提交全部在用 B ；发现冲突后你决定改成 C ，那么当你 rebase 重放的时候所有后面的提交都会不断发生 B 和 C 的冲突）。但这都可以通过减少 commit 修改量和 squash 改善，相比起三路合并能由（虽然存在疏忽的）正常操作产生 **无感知的** 丢修改相比，成本显然要低得多