另外建议不要把其他国家金融历史套在中国上面，中国的金融比较特殊，特别是跟资本主义国家比起来，中国的宏观调控是个大变数。

这个问题要从贷款者和放贷者双方的角度去考虑。

放贷者角度来看，这实际上就是一种投资行为，本金是有限的，钱一旦贷出去了，在收回之前是没法用于其他投资的。
首先确保自己投出的钱能保值，且可以产生利润；
其次是总利润价值最大化，比如投入相同的本金，30 年怎么说也得比 20 年赚得价值多，要想实现这个“多”，可能需要单个客户贡献的总利润多，也可能需要客户数量多，当然两者都多是更好的。

他们要确保赚钱，那么肯定会综合考虑多种因素进行计算，比如货币的升值贬值、抵押品升值贬值（搭配违约风险概率来看）、潜在贷款意愿（市场需求量）；也会参考其他业务的配比，使得整个机构综合利润和风险有一个合理的平衡。

这是个概率问题；
你是相信放贷机构的精算师足够专业，计算结果大概率应验；
还是希望放贷机构会有翻车的时候？

所以我觉得放贷机构给出的贷款方案是有参考价值的，大概率是贷款时间越长、贷款者付出的总价值越多，而这个价值不一定反映在货币金额上，而是反映在特定时期的货币购买力上。

对于放贷机构来说，房贷属于风险较低的投资，低风险投资会被作为保障来平摊更高利润投资的高风险，即便高风险的投资失败了，低风险投资也能保障稳赚不赔，只是净利润少些而已。
那么个人投资，是有可能赚到比放房贷更高利润的，只需要找比放房贷更高利息的投资渠道就可以了，但利息与风险成反比；而且个人承担风险的能力通常不会比放贷机构更强，会比放贷机构有更高的概率赔钱。

那么剩下就是做个选择：
是付出更多利息来保障自己大概率不赔更多；
还是希望风险不会发生在自己身上，看能不能少赔的基础上还能赚一笔。

当然不同放贷机构的情况不同（比如利润来源不同），计算出来的结果也会有差异，这个就得看贷款者是否能发现针对自己的情况最合适的贷款，甚至捡到漏。

对于我自己来说，因为个人通常本金很少，通过金融来赚钱可能费力不讨好，还不如找个高薪水的工作，或者做些副业来得实在。

最近几年感觉网红店都不大行。

你找那种开的时间比较久的店，一般都有过人之处。

好家伙，竟然还没进水深火热。

Go 只有在国内这么火，海外其他地方还是比较百花齐放的，到现在不少人用 PHP 、Ruby 也没见人鄙视。

国内普遍从众，而且危机感过强，以至于一门技术只要有较大的宣传力度都可以有不错的普及率，因为很多人都觉得某技术栈火了，自己不换就很快会被淘汰了。

Go 一开始的宣传定位是系统开发，也确实有 Docker 这种杀手级应用，甚至扬言要取代 C++（后面就知道了这完全是夸大宣传，至少 Google 自己的工程师不买账），最终只在微服务架构中找到了自己的市场（这个领域确实做得挺好），整个技术栈生态也朝这个方向发展，如果要做的项目不是这个方向的，那么很可能选其他技术栈会更游刃有余一些。

我个人的感受就是被其他技术栈的现代化特性惯坏之后，Go 用起来实在难受，说技术倒退是一点都不过分的。

但企业生产从来都不是看这些方面。
当今企业生产有些比较头痛的问题需要解决，如人才紧缺、协作问题、代码维护问题。
而 Go 恰好是一款精准 Hack 企业生产问题的“产品”，从个人角度来看，Go 很简陋，但正是这种简陋，产生了较高程度的统一化，当一个需求只有一种解决方案，或者不同人写出来的代码都是一样的时候，不少企业生产问题也都自然解决了。

Go 很烂，但不得不说，特别适合当下的生产需要。

顶级公司简历多，不愁人才，你如果在业界做不到顶级水准，他们也就只会把你当做一般求职者看待。
那对于公司 HR 来说，简历过多，筛简历的产能不足，最有效的方式就是限定一些硬性要求，来筛掉符合要求概率较低的简历，虽然有错过合适人才的可能性，但概率很低，可以接受。

我曾经有一位同事，初中毕业后就直接当程序员了，自己学习比较刻苦，同龄人大学毕业的时候他已经有 7 年工作经验了，可以承担中高级工程师的工作，跳槽是找到了工资更高的工作。

我想说，不那么看重学历的工作机会还是存在的，就是看你愿不愿意去发掘，毕竟对于企业来说，效益是比学历更重要的。

当然你想深造也不是不可以，但不建议是以求职方便为目的，因为大厂 HR 今天会拿学历来卡你，明天可能就是拿“第一学历”来卡你，最重要的还是得自己在业界做出名堂来。

第一反应是查证一下，不要让老爹被骗了……

@tmacLiu9527 #10
macOS Monterey 12.0.1
Firefox 94.0.2 (64 位)
搜狗输入法 6.0.2.12450

首页搜索框没问题，结果页上面的搜索框有这个问题。
试了试 Chrome 和 Safari 没这个问题。
Firefox 上试了 Google 也没有这个问题。

其实很多时候不是创业点子好不好的问题，而是团队怎么活的问题，这个问题能解决的话，市场是可以慢慢开拓的。

MacOS 下使用搜狗输入法没法输入中文……不知道是为什么。

徒弟是要挑的，不是什么人都拿来培养，一方面是适不适合当自己的徒弟，另一方面值得为这个人投入多少精力，都是可以拿捏的。

我培养过的徒弟都挺优秀，而且都跳槽出去了，我自己将来想换工作的话，这都是内推渠道。

前面根据运营商和归属地可以社工一下吧，除非你连归属地都不清楚。

当我们讨论“安全”的时候，应该讨论具体问题，或者说“希望防止什么安全问题的发生”。

HTTPS 的“安全”基本指的是点对点加密安全，防止数据发出后被其他人拦截获取到内容。另外 HTTPS 还能在一定程度上起到间接识别数据接收方的作用，因为仅有真实的接收方有私钥，只要你用可靠的公钥加密数据，也就只有真实的接收方可以解密数据。

除此之外的安全问题，可能都无法靠 HTTPS 来解决。

回到题主的问题：

1. HTTPS 解决的安全问题和签名、验签解决的安全问题不是同一类问题，签名、验签通常是用来让接收方识别发送方的身份（你是谁），也就是防止其他人冒充身份发送方给接收方发送信息，这需要发送方将公钥保密，而 HTTPS 通常使用公开的公钥，所以接收方通常信任所有使用公开公钥的发送方（私签证书的场景除外）。

2. 大多自有系统内的身份鉴别是客户-服务的双方场景，所以身份鉴别机制可以设计得简单一些； OAuth2 是针对三方场景进行设计的，即第三方身份鉴别服务-服务-用户，自有系统也不是不能用，只不过多数情况下没必要。

3. 这些都是最细粒度的工具，可以被用来做各种用户会话机制的设计。用户会话机制按照将会话信息存储的位置可以大体分为客户端存储和服务端存储两类；服务端存储就是客户端仅保存一个 ID ，客户端发请求到服务端的时候携带这个 ID ，服务端根据 ID 查找到会话信息，再判断用户是否有权限进行操作；客户端存储就是将会话信息进行加密存储在客户端上，客户端每次请求服务端都携带这个密文，服务端解密密文再判断用户是否有权限进行操作。服务端存储的好处是支持服务端自主踢掉用户的会话，缺点就是占用服务端存储空间，且对于分布式服务来说需要确保各节点处理会话信息的一致性；客户端储存的优点相反。当然架构设计都不是绝对的，也有混合方案，要看实际需求。

4. 简单理解就是 HTTPS 单项认证会让客户端验证服务端的合法性，双向认证就是在此基础上服务端也会验证客户端的合法性，跟签名、验签不同的是，这种验证不会关心“你是谁”。

5. 抓包仅能看到 API 的表征，但看不到具体含义，比如我传餐 a=1&b=2&c=3 ，没有文档你很难知道 a 、b 、c 都代表什么意思，取值范围是什么，对于 API 的设计者来说，可以使用易于理解的参数命名方式（如 name 、password ），也可以用不易于理解的命名方式，使得搞破坏的成本大大增加。所以 API 文档能不能公开，得看具体情况。

最后一个问题，签名、验签的作用我上面都说了，所以不算过度设计，HTTPS 基础上再加加解密可以进一步提升遭到攻击的难度，可以防范如客户端被安装了恶意证书的极端情况。

工具是用来解决问题的，去找能解决问题的工具，然后选择最合适的就好。

我遇到过一种场景，就是系统是只读的，只有 home 目录是可写的，这时候如果熟悉 Mac 下的 brew 的话可以直接在 home 里装 brew ，而且可以配置成使用现成的二进制包，没有二进制可用的时候才会编译；不过安装手册比较奇怪，按照手册安装会有问题，得自己折腾，感觉 linux 下用这个的少。

你 throw error 的时候是可以先 new 一个 Error 对象，然后给这个对象塞自己的自定义字段，然后 router 里 catch 到这个 error 之后拿你自定义字段看一眼，然后再根据当前 router 的情况决定如何返回 response 信息。这种做法会把 HTTP 协议层和业务逻辑层区分开，使得 createOrder 可以被多个 router 复用，每个 router 又能根据自己的情况来自定义返回。