建议坚持到读博。

说起杰森斯坦森就想起布鲁斯威利斯，老一代硬汉代表演员之一，虎胆龙威系列挺经典的。

第一滴血系列，史泰龙的其他电影也都可以找一找。

说起史泰龙就不得不提州长。

John Wick 系列，最近看了一部设定类似的叫 Nobody 。

连姆大叔的营救系列，比如飓风营救。

成龙大哥很多片子都很硬。

@yitingbai #6 这个游戏好在任何喜好的人都可以在其中找到自己喜欢的玩法。

你不喜欢跑酷，有人喜欢，在 MC 里：
有的人喜欢玩红石电路，
有的人喜欢玩像素画，
有的人喜欢玩 RPG，
有的人喜欢玩开箱子，
有的人喜欢玩生存，
有的人喜欢玩建筑，
有的人喜欢玩生产线，
有的人喜欢玩音乐，
……

我是从 2012 年开始玩 MC 的，玩了这么多年确实有点腻歪，但如果没啥游戏可玩又想玩点啥的话，永远有个选项是开个 MC 。

这种类比没有意义，绝大多数技术思想都是可以跨技术栈的，比如你说的这些用 JS 也可以实现，只不过可能写法和其他语言不同而已。

换言之，如果你用 TS 来完完全全套 Java 的实现方案，你会发现巨 TM 难用，这不是因为 TS 不行，很可能是不应该这么用。

记得早先有些用 Java 很多年的老哥换 TS 技术栈非要找一套跟 Spring MVC 完全一样的 TS/JS 框架来用，最终代码写得也让人怀疑人生。

@johnsona #86 是 UI，可以做为 K8s 的前端，如果不装 K8s 的话，本身就支持添加多台机器作为 Endpoint 分别进行管理，虽说此时没有集群管理的能力，但是比手打指令方便太多了，特别是给容器更新镜像的时候。

都用容器了，说明对这点点的性能损耗应该是能够接受的，K8s 只是做调度和中间件，实际应用还是跑在 Docker 、Podman 之类的容器里的。

不同的项目情况决定是否适合用 K8s，我说说我们的情况吧，K8s 主要解决我们分布式角度的问题，应用很多，每个应用都需要部署多个实例作为集群，然后我们有多台服务器，以往是限定特定几台服务器只能部署特定的应用，用 K8s 可以把这些服务器看做一个计算池，不需要关心集群是如何分布的，也可以按照负载情况动态调整分布，这样能进一步榨干服务器的性能，不会有的机器超负载、有的机器空转。

另外就是微服务化之后，需要使用中间件来保障微服务之间通信的可靠性，比如需要熔断机制来避免雪崩，类似的这种服务与服务之间协作的问题，K8s 提供了大量插件，可以直接用。

最近在看 K8s 的 Secret，可以用 K8s 集中管理应用的配置，比如数据库连接地址、密码秘钥啥的，这是非侵入性的，而且可以统一管控，避免由开发人员泄露。

总之这些都是工具，最好是了解一下 K8s 能干啥，然后看看目前项目流程上是否有痛点可以用 K8s 的这些特性来解决，再评估成本如何，最终就能决定是不是要用了。

我家里自己的服务器也用容器，但只有 2 台机器，所以用的 Portainer，能提高不少便捷性。

一直都用的标准配置，所以没遇到相关问题。

Windows 的凭据管理确实很难用，发生过勒索病毒连着 samba 设备一起加密的情况，那之后我就在 Windows 上只挂载只读 samba 设备了，或者用 cyberduck 或 filezilla 连 ftp 或 sftp 。

但 cyberduck 和 filezilla 好像没提供 samba 协议支持，不知道为什么，不过我的 nas 开了多种协议，能用啥就用啥。

上面代码编辑有问题，更新一个正确的版本：

// 此时没有 f
(() => {
f = -1;
// 函数块内：-1
{
f = 1;
// 块内：1 函数块内：-1
function f() { 'A' }
// 块内：1 函数块内：1
f = 1;
// 块内：1 函数块内：f()
f = 2;
// 块内：2 函数块内：f()
function f() { 'B' }
// 块内：2 函数块内：2
f = 3;
// 块内：3 函数块内：2
}
console.log('f =', f); // 输出函数块内的 f 值，即 2
})();

第一次函数声明的时候就是做了值的复制，所以内外都是 1

可以逐行调试，然后看每一行执行完后，f 在不同作用域下的值是什么：

// 此时没有 f
(() => {
f = -1;
// 函数块内：-1
{
f = 1;
// 块内：1 函数块内：-1
function f() { 'A' }
// 块内：f() 函数块内：f()
f = 1;
// 块内：1 函数块内：f()
f = 2;
// 块内：2 函数块内：f()
function f() { 'B' }
// 块内：2 函数块内：2
f = 3;
// 块内：3 函数块内：2
}
console.log('f =', f); // 输出函数块内的 f 值，即 2
})();

可以看出来，把操作分成两类，一类是赋值，另一类是函数声明。
赋值的逻辑很简单，就是直接影响当前块内作用域的 f 值，执行到哪就赋值成啥。
比较反常识的是函数声明，可以看到函数声明的时候其实只把当前块内作用域的 f 复制一份放到函数块内，第一次和第二次函数声明都是这样的，如果当前块内作用域块内没有 f，那么就会在当前块内作用域声明一个 f 变量，再把函数赋值上去，紧接着再把块内的 f 复制一份到函数块内作用域。

以上是我根据行为做出的推断，实际上还是得看 ES 标准以及引擎的实现方案。

不过这个说白了还是老生常谈的 ES5 作用域提升的特性，在严格模式+块级作用域下是不会有这种现象的，而且如今的商业开发也极少会考虑保留作用域提升特性，拥抱 ES6+或使用 TS 都在团队开发效率方面有很高的回报。

完全取决于家长想花多少，必要的支出如果你自己付不起国家会有福利政策，吃不起饭还要低保呢。

但现在人对养孩子这件事比较严肃和谨慎，不像以前只管生和解决温饱就可以养大孩子，精神和发展方面的支出更大。

没在 Linux 上装过杀毒软件，不过应该也有，如果希望有杀毒软件来作为保障的话也可以装一个。

不过系统安全策略、安全运维流程、人员安全意识都要有的，发生过装了杀毒软件的系统由于人员被误导手动关闭了杀毒软件导致病毒发作的案例，可见杀毒软件不能解决所有问题。

另外系统安全更新能装的全装上，软件也尽可能用正在维护的版本及时更新，很多软件会在新版本修复安全漏洞。

用 U 盘系统引导，然后 dd 备份系统磁盘或分区，出问题再 dd 回去就行了，这是最简单直接的方式，如果有高级需求可以看看其他楼的答案。

绝大多数企业都不会主动做这种东西的，肯定是因为有红头文件要求这么做，现在几乎所有运营 APP 的公司都在抠用户隐私保护的法规和标准，就是因为这个，因为你不照做的话，就会有一道行政处罚下来。

实际上也不能说这个政策一点用都没有，其实可以罗列一下近些年来各 zf 部门、人大代表提出的各种草案，然后分别分析一下利弊，没准当前这个是最适合当下环境的。我举个栗子，之前有人大代表建议立法让各公司在后半夜停服，你再看看，是不是现在的政_策更人性化一点。

一方面，如果现在没有合适的办法能够在 80%的程度上解决问题，但有个办法能在 20%的程度上解决问题，如果你是 zf 官员，你是选择先上这个 20%的方案然后再慢慢研究其他方案，还是啥方案都不上，死等 80%的方案出现？

另一方面，即便有能解决 80%问题的方案，也有可能当前并不具备实施这个方案的前提条件，那么也可能选择先实施一个满足前提条件的、有 20%效果的方案，然后再逐渐过渡到力度更大的方案。

简单来说，这些问题在真正做决策的时候，没法单纯按照方案核心效果来判断，需要考虑的因素很多。

有些词不改发不了。

https://tc39.es/ecma262/

官方标准，看 12.9 章节。

个人倾向于不省略分号，除非有 standardjs 的 linter 保障不出问题，但为了养成好习惯以便于在任何环境都能写出可靠的代码，我也不用 standardjs 。

个人来讲，大概率不会用。

可以尝试虚拟偶像动态壁纸，粉丝经济还是可以探索的，只不过就是 IP 比较贵，以及需要较好的 DRM 。

但不管怎么说，这都是非必需品，市场极其有限，且用户忠诚度较低。

@sillydaddy #59 一般图片上的明水印的作用只有一种，就是标识来源，但你设计的水印除了标识来源以外还有另外一个作用就是定位盗版者，定位盗版者需要水印能够被解码成盗版者的标识。如果通过组合 abc 来解码出盗版者的标识的话，万一盗版者运气好修改了 abc 三者之一，则 abc 信息损失，你知道 abc 有变化，但无法知道盗版者修改之前是什么样子，也就不能根据 abc 的信息来定位到盗版者是谁。盗版者破解这个措施其实只需要让 abc 三者之一无法被正确解码就可以了，当然前提是他知道有哪些点位是关键点位，这个其实用两个账号看同一篇文章就很容易发现，或者乱改一通恰巧命中。

像图片频域盲水印是模拟信号，本身有很好的容错能力，缺少一部分或者对比度变化都难以对解码信息造成实质的破坏，甚至可以通过实验调优来达到让水印和图片内容一损俱损的程度。

你的方案加的水印是数字信号，本身不具备容错能力，需要靠额外的容错机制才能保障一定的可靠性，比如奇偶校验和冗余，但这样可能就又要在文章中添加更多的点位，如果点位扩展很容易的话倒是没啥问题，但这又受到文章的的篇幅和内容影响颇深。

建议你把自己的方案和其他媒体形式已经在使用的水印方案进行一些对比，然后看看有哪些问题其他水印解决了自己的方案还没有解决，以确定进一步探究的方向。