1. 建议不要为了有一段恋爱精力而强行开始一段恋爱（或单恋），我个人认为恋爱应当是自然而然的、源自由衷喜欢的。否则即便开始了一段恋情你也会越发觉得不满意，从而进一步加重感情上的挫败感。
2. 提升情商，根治直男癌，异性恋的话多了解异性心理，可以关注一些两性心理的公众号，最终要达到做任何事、说任何话都能预判他人反应的程度。
3. 走出去，扩大社交范围，比如参加公司的团建、当地俱乐部、公益组织、会议活动，不一定是以相亲为目的，见的人多了，自然遇到喜欢的人的概率就高了。

https://www.bilibili.com/video/BV1y7411e7nV
https://www.bilibili.com/video/BV1uC4y1x7fa
https://www.bilibili.com/video/BV1kt4y1C7Cq
https://www.bilibili.com/video/BV1MD4y1Q7VJ

我前几个月买了索尼 A9G 。

每个人对于电视的要求可能不大相同，比如我个人看中的是使用体验，所以有广告的一律毙掉。
很多知名电视品牌的显示面板都是 LG 生产的，所以实在懒得选的话可以闭眼选 LG 。
我之所以选索尼是因为索尼有音响耳机的技术，而且用 LG 的面板比 LG 电视卖得还便宜(市场价会浮动)，然后索尼的芯片对画面优化会比 LG 好一些(因人而异)。
上面测评视频里华为智慧屏好像也还不错。
三星的电视品质也不错，但因为不是安卓系统，所以应用生态不行，不过如果长期接盒子也可以考虑。
以上只代表各品牌的高端型号。

OLED 目前还是属于轻奢，有一定的溢价；国内 4K HDR 片源较匮乏，所以显示优势难以充分发挥；虽然没有网上很多人传得那么夸张（可以参考这个 OLED 烧屏测试，类比 SSD 寿命测试，可以换算成自己使用电视的强度来评估是否可以接受其寿命问题 https://www.rtings.com/tv/learn/real-life-oled-burn-in-test ），但是寿命方面确实是有一定风险；所以现阶段 OLED 属于经济条件比较好，买电视能拿出 7000 也能不犹豫地拿出 14000 的人。

各个视频平台也在逐步往 4K HDR 靠拢，但是目前属于较早期阶段，所以如果手里没有多少 4K HDR 的资源的话，买非 OLED 的 4K HDR 也是可以的(眼睛不刁的话)，价钱低很多，过几年等 4K HDR 全面普及之后换 OLED 也不会太心疼。

电视本身就是比较贵的电器，如果某型号卖的很便宜，那厂商一定会在其他地方回本，当然如果经过自己的深入了解认为预算是主要问题、其他的可以接受，也是可以考虑的，届时可以多评估一下做工、售后等问题。

是想问 x86 和 arm 吧，现在 AMD Ryzen 也是 x86 的。

除了虚拟机、解释器类的程序以外，基本上都是要编译成机器码的，操作系统只是提供资源管理的 API，比如创建进程、申请内存、访问文件系统等等。

由于不同 CPU 指令集的中断地址有差异，所以需要不停的编译器来将源代码按照相应的指令集进行编译，而且有的指令 x86 有、arm 没有，相同的源代码可能可以直接编译为调用 x86 的对应指令，但是在 arm 上只能编译成对应的软解方案。

不是系统开发专业人士，可能说得不准确，请大佬斧正。

https://docs.npmjs.com/misc/config
npm 可以用 shell 的 HTTP_PROXY 或 HTTPS_PROXY 环境变量配置的代理。
`HTTP_PROXY=http://127.0.0.1:1080 npm install`
前提是你的飞机可以开启本地 HTTP 代理

定时休息是王道。

如果目前眼睛没有不适，可以先不用考虑。
如果眼睛已经不适了，建议让你的医保发挥发挥作用。

之前看过果壳上的文章，所以对蓝光眼镜存疑，但肯定也不能忽略安慰剂效应，如果带上确实主观感觉上好了，也算是有些作用吧。

可以试试软件防蓝光，很多系统都自带。

1. 自己转好不同清晰度的视频，上传 CDN 。
2. 原片上传 CDN，再用 CDN 的转码服务。

其实本质上两者一样，就看你是把转码成本放在自建转码服务器还是 CDN 平台了。
如果视频是官方发布，不是用户上传，那么可能（每家谈下来的情况不一样）自建转码服务器会相对经济一些。

七牛阿里云用起来应该都差不多，就是看价格谈得如何了，对了，多数厂商都是可以找销售谈价格的。

一般都是网上招募，然后私下联系吧，平台的话也只能做到发布招募，做不到三方保障，更别谈法律问题了。

1. 这个仅仅是 Deno 内部实现的变更。
2. 不影响 Deno 支持 TS，Deno 也声明会永远支持 TS 。 @Oktfolio 所以 TS 还是可以安心继续吹。

确实，如果 Deno 不使用 TS 原生引擎的话，就逃不出 JS 这一步，但问题是，微软是否希望以后搞出 TS 原生引擎来取代 V8，以及让 TS 脱离 ECMA-262 取代 ES 呢？不过微软现在在积极渗透 Chromium 项目就是了。

市场营销本来就是因地制宜的，比如云计算在国外通常是账单制后付费的，但在国内通常是预付费的，你不能说哪个绝对好，还是得看各自的用户是否买账。

B 站虽然整体是二次元风格，但是实际上内容方面已经很全面了，影视、音乐、美食、手工等主题的视频量级也非常大，至少对于我个人来说，我现在虽然每天刷 B 站，但很少看二次元的东西。

“B 站什么时候能成为中国的 Youtube”，这个得看从哪方面来类比，在营销模式方面，优酷、爱奇艺、腾讯视频三家可能比 B 站更像 Youtube，但是这么多年看来，这种模式在国内可能并不能像 Youtube 在国外那样风生水起，所以要么开始探索创造自己的营销模式，要么尝试一下其他案例的模式（如 Netflix ）。

在国外，如果说要做视频，那么首先想到的就是上传到 Youtube ；在国内，如果说要做视频，那么首先想到的大概是当个 Up 主。所以我个人觉得（不代表权威观点）从这方面，B 站可能已经成为了中国的 Youtube 了。

从不在视频中插广告这一点就能看出，B 站很有自己的想法，自己打造出来的全新的模式虽然有一定的风险，但一旦成功就能形成较高的市场壁垒。

@hantsy
URI 不是 REST 的概念，是 RFC-3986，而在这个标准里 URI 的定义很宽泛，并没有强制要求“ID 从来都是放在路径中来表示单个资源”。

我没讲 ID 放在 Path 里，是考虑 Action 会和 ID 占用同一个位置，需要增加额外逻辑判断 Resource 后面跟的是 ID 还是 Action 。如果业务逻辑上比较简单，且常用 ID 来定位 Resource，采用 Path 里传 ID 的方式也是可以的。
不过并不是说“可以在 Path 里用 ID 来定位 Resource”，就“不能在 querystring 里用 id 作为查询条件”，完全可以两种都用，根据实际业务来制定哪些情况下用 Path 传 ID 的方式，哪些情况下用 querystring 的方式。
我以前遇到过在批量操作的时候希望定位多个 ID 的需求，这时候就只能通过一些数组传参的方式来实现了（比如 GET /user_batch?id=abc&id=cba，具体看团队内的标准）。根据自己的实际需求来设计就好。


@iplayio2019
代表批量资源的时候不建议使用英文复数，因为英语的构词法是不严格的，遇到单复同形的情况下(比如 fish)就没法区分单个还是多个了。

REST 是制定项目 API 标准的参考思路，而不是 API 标准，其本身也没有提供 API 设计细节，具体的解决方案还是得根据实际需求具体设计。

我只是分享我自己踩过的一些坑，指出哪些设计适用哪些情况、不适用哪些情况，希望能帮助楼主少走弯路，各位回复的时候也请说明一种方案在哪些情况下好用，在哪些情况下不好用，一个需求在不同情况下能提供多种方案就更好了。

一方面是操作的时候仔细一些，确保输入的指令无误再执行；另一方面可以借助一些工具来确保可以恢复误操作，比如 trash-cli 这种工具可以使用 trash 指令来将文件放入回收站。

看了 API 的定义之后，认为完全没有遵循 REST 的方法论来设计。

可以看看维基百科，国内也有很多 REST 的书可以看，英语过关的话可以看看 Roy Fielding 的 paper 。

我举个例子吧，就说你现阶段做的用户部分。

REST 是围绕 Resource 来设计的，那么“用户”相关的功能肯定都是以“用户”为 Resource 的，而 REST 提供了一个基本思路就是使用 HTTP 的 method 来代表逻辑上对资源的操作：
POST：创建
GET：获取
PUT：修改
DELETE：删除

那么相应的，用户的 API 有这几个：
创建一个用户：POST /user
获取一个用户：GET /user
修改一个用户：PUT /user
删除一个用户：DELETE /user

使用 querystring 来进行查询，比如删除 id 为 123 的用户：
DELETE /user?id=123

有时候会有需求一次对多个用户进行操作，那么这时候有两种思路：
1. 把“一批用户”作为一个独立的 Resource：
创建一批用户：POST /user_batch
获取一批用户：GET /user_batch
修改一批用户：PUT /user_batch
删除一批用户：DELETE /user_batch
2. 让“用户”Resource 具有“批量”的 Action：
创建一批用户：POST /user/batch
获取一批用户：GET /user/batch
修改一批用户：PUT /user/batch
删除一批用户：DELETE /user/batch
用哪种思路可以带入你的实际业务来看未来哪种会更好用一些。

那么对于“登录”、“登出”等特殊逻辑，如果依然在用户 Resource 上考虑，是无法简单使用 HTTP method 来代表的，可以抽象成独立的 Resource：
登录（创建一个会话）：POST /session
登出（删除一个会话）：DELETE /session

修改用户昵称和修改密码都是 PUT /user，可以通过判断 Request Body 里传入的是 nickname 还是 password 来决定究竟是调用修改昵称的逻辑，还是调用修改密码的逻辑，还是两个都调用。

以上就是 RESTful API 设计的一点皮毛，一些需要注意的点：
1. REST 是一种设计风格，本身并未提供 API 的细节设计，需要自己理解 REST 解决痛点的核心思路，再根据实际业务情况来设计 API 。
2. 如果业务上没有相应的痛点需要 REST，甚至本身与 REST 的思路相矛盾，就不要硬上 REST，例如微服务通信非常适合用 REST，但 BFF 或 API 网关层接口聚合可能更适合用 GraphQL 。
3. Resource 就像是一个对象，其所有接口都应当使用同一套属性定义，比如修改密码的时候使用 password 字段在代表密码属性，那么在获取用户密码哈希的时候就不应该用 password 字段了，应该用 passwordHash 字段，password 字段应该始终代表用户的密码属性，即便这个属性没有存入数据库无法被 GET 出来。
4. API 上定义的 Resource 不一定要和数据库里定义的 Model 一致，比如用户会话“Session”Resource 可能不会存在数据库里，但是在 API 上它可以是个 Resource 。一个更极端的例子是 API 层的用户 Resource 叫“User”，而底层服务数据接口层面可以叫“Customer”，而且双方的数据结构可以有很大区别，通过业务逻辑来进行映射。
5. 一个 Resource 可能会有多个逻辑对应同一个增删改查操作，这时候可能就需要引入 Action 机制，即在每一个 Resource 后面都可以跟一个 Action，来代表执行不同的功能逻辑，如果有多级 Resource 的话，也最好确保每一级 Resource 后面紧跟的都是其 Action 。
6. HTTP 标准并没有说仅 GET method 能用 querystring，甚至没有规定 GET method 不能用 body （虽然很多 HTTP 库禁止 GET 请求传 body，但并不说明标准不允许这么做，实际上 Elasticsearch 的 API 就是在使用 GET method 请求的同时传 body 的），实际上 HTTP 标准中 method 、querystring 、header 、body 是分别定义的，可以自由组合使用。
7. 要合理规划 method 、querystring 、header 、body，哪类参数应该用什么机制来传，要做到始终遵循一套标准。

SSH 只是一种远程连入的方式，而登录到一个用户是有很多种方法的，有正常的方法，也有利用漏洞越权操作的方法，所以最好彻底禁用运行应用程序的用户被登录，也就是说哪怕我从别的用户使用 su 指令要求切过去，甚至哪怕我走到机房里直接操作那台机器输入正确的账号密码，都不能直接登录这个受限用户（在不能登录到 root 用户改系统配置的情况下）。

用户的登录是由系统底层来控制的，系统配置里会记录不同用户对应的默认 Shell 是什么，然后当用户登录成功的时候会自动启动相应 Shell 以便于用户操作，但如果系统里对应这个用户配置的 Shell 不是一个可用的 Shell （比如 /sbin/nologin ），那么即便用户登录成功了也无法操作。
具体方法可以参考这个：
https://www.thegeekdiary.com/unix-linux-how-to-lock-or-disable-an-user-account/

Deno 只是个应用引擎，顶多带有一定的沙盒功能，Deno 的依赖包是直接暴露在 Linux 文件系统里的，不是放在 Deno 沙盒的文件系统中，而沙盒只能保证代码使用沙盒来执行的时候不会逃逸（越权），但无法保证代码不利用沙盒以外的机制运行，理论上恶意代码完全可以不依赖 Deno 来访问当前用户的所有权限（比如 Linux 系统层级的木马，利用系统的调用来自动运行，或者冒充正常程序引诱管理员运行）。
如果确实有需要将代码与 Linux 系统进行隔离，可以使用具备文件系统隔离能力的方案，比如容器和虚拟机，所有代码都存在于 image 中，不会直接被系统或管理员调用，必须在容器或虚拟机里运行，而容器和虚拟机确保其不会逃逸。
用容器和虚拟机还有一个好处，就是 image 可以在 CI 环境里构建，构建完成能够进行安全扫描，确保没有恶意代码再部署到服务器正式环境，这样也可以消除恶意代码在应用业务层上的破坏。

Linux 的权限机制很强大也很灵活，所以安全与否全在于管理员制定什么样的策略。

首先，权限最小化原则。任何应用程序都应该运行在一个特定的用户下，这个用户仅被授予应用程序运行所必须的权限，即便不小心在应用程序上引入了恶意代码，也因为没有事先授予权限而无法进行更高级别的破坏；影响也被限制在应用程序层面。

一旦准许一个用户被 SSH 登入，那么只要它可以进入一个正常的 Shell，就拥有了这个用户的所有权限，但通常配置“是否准许一个用户被 SSH 登入”是需要高级权限的（比如 root ），那么完全可以禁止应用程序运行所使用的用户被 SSH 登入，可以使用另一个用户作为 SSH 登入专用的用户，然后将这个用户的权限限制在仅能使用 su 指令切换到其他用户，而 su 指令是需要输入切换的目标用户的口令才可以的，安全性有保证。同时建议在服务器上禁用或移除 sudo 指令。

建议直接向面试官或者 HR 问项目流程或管理模式，一般都会说的，至少我当面试官的时候会说，不过确实问的人少。

招聘的时候如果做不好双线选择的工作，那么新招的员工短期离职率也会较高，所以有什么问题直接问就好了，旁敲侧击的话花了很多功夫，得到的结论还不一定准确。

不过说话确实是一们艺术，如何能尽可能多得探坑，又不至于让面试官或 HR 反感，得需要好好想想。

先看现在的搜索引擎是怎么工作的。

搜出来的页面，如果有用户想要的链接，用户会主动去点，没有的话用户会尝试换关键词搜索，直到搜到了想要的链接就会点击。

那么搜索引擎只需要看用户点的是哪一个链接，然后根据链接在搜索结果的页数及位置来评估当前搜索结果是否足够好，如果普遍用户翻到第二页才点击链接，那么显然这个搜索结果是不够好的，搜索引擎可以自动把链接提到第一页。
然后根据相同的关键词搜到的各项结果的点击情况来排列前后顺序。
如果想做个性化的话，可以拿公共的排序作为默认排序，再根据个人的搜索和点击历史来动态调整这个用户看到的搜索结果的顺序。
再准确一点的话，可以关联用户一次连续会话中搜索的关联词，比如你先搜了意大利音乐，紧接着又搜了太阳，那么就会前排显示意大利歌曲《我的太阳》的结果。
如果想更准确的话得让搜索引擎理解搜索关键词和搜索结果之间的关系，这个就得上自然语言处理和人工智能了。

通过用户的搜索行为、点击行为以及所点击的链接在搜索结果的位置，基本就可以非常准确和全面地反映用户对搜索结果的满意度了。楼主可以思考一下，点赞是否能够比上述方案更加准确和全面的反映用户对搜索结果的满意度。

搜索引擎发展这么多年有很多技术来提升搜索结果的质量，但为什么搜索结果还是没有达到完美的程度？

不同人对同一事物的描述很可能是有差异的，而相同的关键词在不同上下文也可能代表不同的含义，人类之间交流还有可能因为信息不对等而产生误解，更何况搜索引擎。

所以其实各大搜索引擎都很清楚每个用户对每次搜索结果是否满意，问题是知道了也没用，提升搜索准确性本身就是个很难的问题。

pm2 目测就是 process manager 的缩写，官网上也说它就是个进程管理器，虽然通常都是在 Node 技术栈上用。

容器化+K8s 是发展趋势，可以了解一下。

问题没看明白。

1. MongoDB 支持自动创建集合，你在使用一个不存在的集合就会自动创建，就是索引需要额外创建，集合的配置也是用的默认配置。
2. 为什么要动态创建集合，都放在一个集合里会有什么问题？
3. 压缩具体直接是什么技术？ WiredTiger 存储引擎有压缩功能，具体文档参考 https://docs.mongodb.com/manual/core/wiredtiger/#compression