我倾向于自我 PUA：生孩子之前其实是在省钱，生了孩子之后才是正常开销；而且生孩子之前可能处于一个舒适圈，生孩子之后为了尽可能减少改变（比如很多人不愿意回有房有亲戚的老家生活），不得不承担更多成本。

生不生孩子是个很严肃的决定，生的话就得有额外成本的预期，不生的话就得有过了岁数就再也不能生的预期，权责对等。

目前各项政策都在朝着养孩子更容易的方向发展，至少今年比去年要好一些了，没准等孩子上学了会轻松很多。

现在 B 站有个设计缺陷，一些情况下会自动使用 H.265 方案，但网站同时又认为你的浏览器没法调用硬解码器，于是就用了软解码，软解又太费性能。

解决方案是切换回 H.264 解码方式（齿轮-更多播放设置-AVC ）；或换一下 User-Agent 为 Safari ，让网站认为你的浏览器可以调用硬解码器，当然前提是你的浏览器真的可以调用硬解码器。

所有事情开始于你的职业规划，一个清晰的职业规划可以让你知道自己需要做什么事情。

或者说，尝试回答一个问题，三年后、五年后，你希望你在一个什么环境下，以一个什么状态，具备什么样的能力，做什么事情，获得多少报酬。

两年前吧，正处于 Chrome 疯狂改界面的时期，改来改去又不怎么给 flag 让用户自己设置，有点不爽；同时安卓端的 Firefox Nightly 又支持装扩展，于是我就全部迁移到 Firefox 了；一开始 Nightly 会有些 bug ，现在已经正常，除了个别功能会被 Google 限制，比如谷歌翻译。

如果想尝试 Firefox 的话一定注意用国际版，不要用中国特供版。

心态要变一下，编译器不让你通过是在帮你避免一些风险，总比运行的时候出了问题再做一脸懵逼的 Debug 要好；而且 Rust 编译器的报错信息已经写得非常贴心了，只要静下心来认真看，大多问题都比较容易解决的。

除此之外也要养成良好的代码习惯，Rust 非常灵活，所以对开发者要求很高，因为需要开发者在众多实现方式中选择最适合当前情况的方式，选错了往往就变成了技术债务。要是不想有这方面的负担可以用 Go 。

用其他语言未必也有成就感，随便写写就能跑，除非你的成就感止步于可以运行，如果经过千辛万苦的修改最终让 Rust 写的程序可以编译通过，那岂不是更有成就感的一件事（自我 PUA ）。

实际上很多时候觉得用一个语言比较痛苦是因为自己对这个语言掌握不够娴熟。比如 JavaScript 的弱类型被很多人诟病，甚至一些人宣布以后完全用 TS 来替代 JS ；但对于真正熟练掌握 JS 类型系统的人来说，脑子里完全可以精准预测代码执行后的结果，并且有多种手段可以避免出现问题。

Rust 再怎么抽象，毕竟还是跟 C/C++一个层级的语言，需要对内存的工作原理以及 Rust 对内存的处理机制十分了解才可以明确知道如何运用各项语法特性。其实跟 C/C++比起来可能还降低了处理内存问题的负担，毕竟大多问题编译器就可以帮你检查出来。

我自己也是学了三四遍，主要原因是平时用得少，容易忘。
学的时候可以考虑做些笔记，形成一个自己的速查手册，特别是自己需要花一些功夫理解的概念，以及跟自己学过的其他语言的类似功能的对比和辨析，等用到需要复习的时候能帮你快速想起来就可以，就没必要再去一个字不差地看官方教程。

先确定自己希望跟什么样的人一起生活。

然后多接触一些人，哪怕不是以搞对象为目的的接触，比如参加一些培训、社团、公益活动，哪怕遇到适合的人概率低，基数大了总会遇到。

提升自己的情商和穿着装扮，基本上是预测对方反应——做行为——观察——修正预测的循环。

英文用谷歌
中文用必应
政务用百度

Google 搜一下你的错误信息，就能搜到结局方案。

比如看一下这个 https://github.com/ant-design/ant-design-pro/issues/9272#issuecomment-1086828874

或者国内站点看一下 Node v17 的更新 https://developer.51cto.com/article/687259.html

生产项目建议用 LTS ，除非你对项目的代码、依赖的细节非常了解，像 React 这种稍微复杂一些且应用广泛的依赖最好还是用 LTS 。

个人认为 Go 是一款精准面向解决企业生产效率问题的“产品”，语法和特性有些落后和简陋，但同时上手简单、千人一面，再加上性能还不错，所以非常适合企业快节奏生产。

个人认为 Rust 和 Go 相反，Rust 的设计理念和特性都很先进，当前优势在于比 C/C++等同类系统开发语言可靠，软件出厂质量高，长期能节省很多潜在 Debug 成本。

所以如果一个领域已经可以成熟地使用 Go 来生产，可能大多不会选择 Rust ，但如果一个领域往常只能选择 C/C++，Rust 非常值得考虑。

Rust 目前比较集中在系统开发领域被使用，Go 目前比较集中在 Web 微服务领域被使用，看你想在哪个方向就业。

当前很多 Rust 项目需要和 C/C++代码交互，所以很多要求应聘者同时具备一定 C/C++基础。

我学了好几次 Rust ，学好几次主要是因为平时用得少，一段时间后就会忘，如果能偶尔维护个项目啥的可能会好一些。

个人认为在系统开发领域非常有前景，但在其他领域缺乏杀手级别的特性，不过这语言一直在更新，说不好未来会咋样。

没在阳台种过菜，但家里有不少绿植。
选土注意虫卵和孢子，毕竟是在室内。

如果两个分支从某一次提交前的所有提交都一样，那么可以说这两个分支是同源的。

但 A 是从 B 分出来还是 B 是从 A 分出来，就没法说了。

举个例子，有一种操作是从 master 里分出分支 A ，然后没有任何提交又从分支 A 分出分支 B ，此时分支 B 算是从哪个分支分出来的？
在从 master 分出 A 之后，master 上有新提交，A 上没有，把 master merge 到 A 上，再从 A 分出新分支 B ，此时分支 B 算是从哪个分支分出来的？

这应该是个 XY problem ，可以说一下背景和需求。

装 Windows 第一件事就是关闭自动更新和自动启动，不然半夜睡觉时老自动开机。

改组策略、服务、注册表等方式可以做到，可以搜搜相关的教程。

家庭版应该也有办法操作设置，比如改注册表和使用 PowerShell 装一些包，具体也可以搜一下。

都是管理上的问题，前后端应该在工作内容方面有个清晰的界限。

这个应该是期权不是股权吧。

期权就是员工可以在行权时机到来的时候用极低的价格购买一定数量的公司股票，只有行权之后才是获得了股票。

比如给你的期权是 10 万份，分三年分别每年可以给你 20%、30%、50%，然后到了行权期的时候每份 1 块钱等数量换成股票；
那么你一年后就可以获得 20%也就是 2 万份期权，二年后获得 3 万份，三年后获得 5 万份，加起来一共 10 万份，这时候你手上只有期权还没有股票；
公司给你签订的期权合同里会说明什么时候可以行权，比如公司上市、被收购、回购的时候，你才可以用 1 块钱一份的价格把手上的 10 万份期权换成 10 万份股票。这时候如果股票可以在股市交易，且每股价格高于 1 元，你卖股票就可以换更多的钱。

以上是一种常规的期权方案。

看题主的描述，感觉还有些不同，就是题主的公司是每年都要交钱，我以为是可以每年行权，比如一年后就可以花 1 元一份的钱来获得 2 万份股票；
但看到下面说离职返还的要求，感觉每年还不是行权，只是花了行权的钱，但没有给你股票，相当于行权的钱在公司那存着，等行权时机到了的时候才会给你股票，三年内离职还要损失 20%行权的钱。

感觉有点不靠谱，跟一些骗局有点相似，就是公司没钱了，然后让员工垫，后面能干就继续干，干不了老板卷钱跑。
而且如果三年后要上市的话，现在就应该开始准备上市的流程了，怕是三年又三年，你受不了离职了公司收回期权把行权费用退给你，钱白被公司拿去周转了一下。

总之股票到手才算你的，只要没到手你花多少钱都没意义。

可以部署测试环境，然后测评的时候驻场或连 VPN 测评。

等保测评内容涵盖开发和运营的单位，客户运营的话其实很多关于安全管理方面的测评都是测你的客户；网站技术部分扫一扫漏洞，密码策略之类的符合要求就行。当然开发方还得提供一些开发管理制度和设计文档。

客户着急上线，客户要求过等保，其实是客户自己赶自己。如果客户在管理制度方面不完善，那得让客户自己去完善，或者让客户自己找咨询公司去完善，你们记住不要替客户去做就行，这应该不属于你们的合同范围。

401 指的是 Unauthorized ，是接口要求必须登录过才可以调用，不是登录失败。

HTTP 是有标准规范的，所有状态码都有定义。https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

需要注意的是：
1. 标准里对状态码的定义仅与 HTTP 协议通信的状态有关，跟业务无关，比如 401 仅代表 HTTP 协议层未认证，不代表业务上未认证，虽然有时候两者是同一件事。
2. 通用的 HTTP 客户端和服务器软件及其相关的框架和库都是会默认遵照 HTTP 标准规范来设计的，你可以不按标准使用，但你使用的软件、框架和库可能依然会按照标准来反应。
3. 有的 API 设计风格（如 REST ）会把业务状态和 HTTP 状态绑定一起，但这是建立在业务状态足够简单的基础上的，HTTP 状态码就那么多，无法把所有业务状态全映射到，比如登录失败可能有多种原因，客户端需要对不同原因进行判断再做反应，此时仅一个 400 状态码是没法解释清楚的。

建议先对 API 进行梳理，然后划分出哪些接口要用什么设计风格；对于可以遵照 HTTP 标准来设计的接口，需要去分别考虑每种返回情况的 HTTP 状态是什么、业务状态是什么，给出正确的 HTTP 状态，并在载荷中写明业务状态。

自己用怎么折腾都行，给家人用还是可靠性为主。

我的推荐顺序是：商业相册云服务>商业 NAS 产品>自建。

群辉可以考虑，再怎么拉都肯定比自建可靠。