顶楼让我思考。
2 楼让我恐惧。

摸鱼摸出了感情，每天都忍不住找鱼。
/修女震惊.jpg

人类很多事情的发展趋势都是类似，像一棵生长的树：
各分支独立发展 -> 某些分支特性优秀，互相取长补短 -> 各分支趋同，同时有少数分支取得优势地位 -> 英雄主动统一江湖 /事实标准统一江湖 -> 单主流笨重缓慢保守乏味，变成泥足巨人，出现不满，新的分支 -> 回到开头循环

LE 免费证书可以申请通配符证书。
搭配 acme.sh 等自动更新脚本食用风味更佳。

先不说大脑和 dna 的事情。
单以人类目前对大脑的理解透彻程度来说。
大脑 root 权限给人类就跟 linux root 权限给猴子没啥区别吧。

目前可行的方案：
1 ，脱敏后模糊搜索。138****1234 ，脱敏后存明文。
2 ，砍需求，只支持全文匹配，库里存全文的 hash 。搜索时按输入 hash 去匹配。
3 ，原文求前缀子串 /任意子串后 hash 入库存储。搜索时按输入 hash 去匹配。

hash 计算再怎么长都不会比网络传输时间长。
因此，分片校验并传输，利用传输时间进行其他分片的 hash 计算完全足够。
以及，分片的好处不止校验速度，传输出错后的重传也依赖分片。

分片唯一的缺点是不方便做完整文件的“秒传”，但文件共享度低的场景下其实不存在秒传。

另外一个办法就是提前计算好 hash 放在大文件旁边。

@2i2Re2PLMaDnghL 默认名称还拼错了。应该是 Player+随机字符串。

自动化 = 可重复。
例如每次发布 /每次代码变更 /每次提交，都要跑一次核心用例回归。
以前：一次回归人时数 * 每月总次数 = 人月数。
现在：0

老板，我帮你省了 n 个测试人力！

反向思考一下，关系型数据库做不到合并单元格，但可以“拆分”单元格啊。
用户 1, {"1 子用户", "1 子用户", "1 子用户"}
用户 2, {"2 子用户", "2 子用户", "2 子用户"}
返回这么两行就行了。/手动狗头

Links
Useful Links

从邮件自身逻辑表达的完整性来讲，一封邮件讲一件事情，因体积关系被迫分拆，那就不应该使用各邮件分别带一部分 pdf 这种缺乏强关联的形式。这种思路是在鼓励漏掉文件。

一定得强调是一个完整逻辑体，邮件标题 [1/3] 、 [2/3] 、 [3/3] 表达关联性，附件使用压缩分卷强迫关联性和完整性。

base64 基操就是把 8bit 的字节们按 6bit 重新切割并查表转换成对应字符。
那么假设有字符串 abc ，转成二进制 01100001 01100010 01100011 。
按它在原文中出现的 bit 位置，有 6n/6n+2/6n+4 三种情况，
那它被分割的可能性就有三种：
011000 010110 001001 100011 YWJj
0110 000101 100010 011000 11 ?FiY?
01 100001 011000 100110 0011 ?hYm?

所以就去搜这三种情况，搜到了，再解码搜一次确认。

如果在用 1password 家庭版的用户请定期备份密码。
（定期备份常规思路为什么非要强调 1P ？ 1P 和 LastPass 有什么不同吗？言下之意 1P 用户尤其要特别注意备份？）

1. 不要太过于信任官方，
（和官方有半毛钱关系？）

但在出现了这种问题后，我实在是无法再相信 1p
（再次，和 1P 有半毛钱关系？是不是无法再相信心大的自己措辞更准确一些？）

真的，不解释还可以理解为“之前没有意识到拼车的风险而产生了一系列误会”。没关系，安全问题上谁没盲点过呢？

越强行解释，越生动演绎出又傻又强装面子反而更凸显了傻丢了更多面子的喜剧场面。

不为无益之事，何以遣有涯之生？

到底是什么岗位？
就只有我一个人觉得这是一道普通编程题，要求实现的不是玩游戏策略算法而只是实现游戏规则，考察的是候选者的代码基础工程能力而不是算法能力吗？

你这是最初级的掩耳盗铃。被发现后会被打出屎来，而且锅都甩不掉。
高级掩耳盗铃：业务层继续收集，底层发送时阻断。

老板：公司成立起来了，广告也打出去了，客户也忽悠到了。现在就差开工干活了。
小王，公司现在已经有 5w 台服务器了，你得出个方案，负责管好。
小王：我才刚入职就我一个运维怎么管 5w 台？唔。。。先上 V2 求个方案吧。

千变万化的开发团队。