工具服务于需求，没需求硬上肯定添堵。

比如我一开始在电脑上直接跑服务，装各种依赖会污染系统环境，而且也不容易备份还原，后来出于方便就把服务都搬到容器里了。

用不用微服务取决于是否真的需要复用部分服务模块来达到节省开发成本的目的，比如我自己写了几个爬虫来爬小姐姐，但是每个爬虫都单独引一份 Puppeteer 环境导致每个服务程序本身都会占用上 GB 的空间，为了节省空间我打算迁移到 Browserless ，多个爬虫实例共用一个 Browserless 微服务。

我不是 All in one ，我的服务器和 NAS 是两台机器，这样性能、故障隔离。

想要确保数据不丢，没啥好办法，就是冗余+备份。

NAS 上的系统是装在 U 盘里的，深入做了写入优化，确保 U 盘寿命最大化，每天自动任务 dd 备份 U 盘到机械硬盘阵列里，这样 U 盘坏了可以用备用系统进入机械硬盘提取备份来恢复。

服务器的思路是差不多的，系统和服务装在 SSD 上，数据不存本地，经 NFS 存到 NAS 的阵列里，因为 SSD 里的数据很少更新，所以只需要每周全盘备份+压缩存到机械硬盘里。

换小的 SSD ，空间分配可能不够灵活？比如你发现有一个用途快用满 512G 了，但同时另一个用途还没用多少空间。至于直通，一方面得看性能提升多少，另一方面也得看你对性能要求是否有极致需求，毕竟已经用 PVE 了性能也不可能完全没有损耗的。

我用过 7 年 MongoDB ，做公司的支付和订单系统的数据库，没出过什么幺蛾子，性能也不错；遇到过觉得不好用的要么是对这个数据库的特性不够了解，要么就是拿来当存关系模型。

查一下数据库日志呗，看看有没有 drop 记录，没有的话问问 VPS 运营商是不是回滚来着，滚到了 collection 产生之前的快照。

@jin7 #7 ES 是搜索引擎，跟 MongoDB 根本不是一类东西，各有擅长的场景，所以通常可以拿 ES 跟业务数据库组合使用，我们之前就是使用 MongoDB 的 Change Streams 特性来同步数据给 ES 用的，用于支持一些实时性要求低的复杂表单搜索场景。

中水就是污水收集起来，进行基本的净化，然后用于对水质要求不高的场景，比如冲厕所和灌溉。
基本可以理解为比雨水、河沟子里的水干净一丢丢，但远达不到自来水卫生标准。

有些小区入户是有自来水和中水双管道的，中水在家里可能只能用来冲厕所，可以节省干净水资源。

注销淘宝、支付宝、手机号，重新办理新的手机号，然后用新手机号开通淘宝、支付宝账号来网购。

你用京东没问题，所以说明至少有一些环节讨债公司是拿不到信息的。

想试验的话也可以一级一级试，比如换个新地址寄个中通快递，看是不是会收到包含新地址信息的短信，收到了就说明中通有内鬼；没收到就可以试着换另一个地址从另一家淘宝店买东西，看会不会收到包含这个地址的短信，如果收到了就说明是淘宝的问题。

看公司氛围和态度吧，越是上规模的公司可能在保密方面要求越高，也就越倾向于公私分开。

我们公司比较小，之前每年有个激励计划，就是中层员工可以申请一台 MBP ，三年内离职收回，连续工作三年后归个人所有，我就基本没有公私分开了。

注意 commit 历史也不能包含敏感配置信息，否则可以被 checkout 出来。

OKR 需要员工自己制定，但制定完成后需要上级审批，一经审批就表明上级签字画押不可否认了。

复盘的时候需要对 OKR 的合理性进行诊断，如果认定不合理，那么审批通过的领导也有责任的。

每个案件都是独一无二的，不能因为一个案件的判决结果而导致以后所有类似案件都是完全一样的判决结果，需要就事论事。

这也是法庭存在的意义，因为事情是复杂的，法条是概括的，所以这其中的灵活性就由法庭来体现，通过举证、辩论，以及对法条思想的解释和扩展，再进行研判。

这方面属于民事诉讼的范畴，很多时候合同、协议更起决定性作用，除非合同、协议条款本身属于法律明确规定违法的行为。实际上一些单位在于雇员签订劳动合、保密协议、竞业协议的时候，会有知识产权相应的条款。比如规定在职期间无论是不是工作时间，员工的任何发明创造和著作都由公司所有，并且需要让员工自己在劳动合同上写明自己已有的发明创造和著作列表，以明确被排除在外。如果明确有这些条款的存在，在其本身不受法律明令禁止的情况下，出现员工非工作时间创作的作品的产权纠纷，单位可能就占有显著优势了。所以签合同、协议以前需要仔细阅读条款。

在用人单位的角度上，也可能存在不同的态度，是仅仅出于防御性目的避免被员工坑，还是想有朝一日能耍流氓捞一笔，而且还存在被收购清点的情况。

其实作为员工，需要有意识避嫌，比如创作前可以先评估一下是否与自己的工作单位有利益冲突，以及可以考虑把产权交接给信任的他人或社区组织，最重要的就是让用人单位没有起诉的意愿，毕竟欲加之罪何患无辞，知识产权也只是众多法律武器中的一种而已。

我在 Windows 上用 Cygwin 装 XServer ，然后在 WSL2 里装 IntelliJ ，可以直接投到 Windows 的 XServer 上，使用起来跟直接在 Windows 上跑 IntelliJ 一样。

WSL 内尽量使用自己的文件系统，建议仅在需要文件传输的时候才在 WSL 内部访问 Windows 的文件系统，以避免一些兼容性和 hook 问题。

有需求就有市场，市场选择就是车前进的方向。

试想这样一个场景：
一个团队用 React 做了一个网站；
后来发现移动端的流量更高，于是就适配了移动设备；
然后发现基于应用商店的运营策略可以带来更多流量，于是想做 APP ，所以用 WebView 做了个 APP 壳，然后内嵌自己的网站；
后来用户反馈在一些复杂页面很卡（当时手机机能还没现在这么强），同时产品经理希望增加一些现有 Web API 不支持的功能。

作为 CTO ，有如下选择：
1. 保留现有 Web 开发人力开发 Web 端以外，额外招聘同等产能的 Android 和 iOS 开发人员，以原生方案重写，开发人员预算增加 1-2 倍；
2. 让所有前端开发人员去学 Dart 和 Flutter ，招聘具备 Flutter 开发经验的人员补足离职空缺的岗位，原有代码推翻重写，缺轮子找替代品或自己造，不过 APP 性能可以改善不少；
3. 试一下 RN ，原有代码可以得到最大限度复用，开发人员只需要了解一下 RN 的使用方法，还能改善 APP 性能。

当然，最终什么方案适合，得经过深入调研和试验才能得出结论，比如也有可能 RN 与原有架构设计方面不兼容，那就可以考虑是不是还要继续走这条路。

Microsoft Remote Desktop ，微软官方的 RDP 客户端。

我家里的宽带有公网 IP ，华硕路由自带 DDNS 和 OpenVPN ，我就是从公司连 OpenVPN ，然后直接用 RDP 连 Windows 。

其实方案适不适合得看你的具体情况和需求。

现在的电脑都会有静电保护功能，有静电的时候不启动，解决办法就是断电，然后按住开机键几秒钟，此时会释放里面的静电，再通电，就可以开机了。

我遇到大多情况都是因为这个，如果靠这个办法解决不了，也有可能是开机键老化了，如果机箱有重启(reset)键的话，你可以尝试把电源和重启键的线交换插一下，然后用重启键来开机，如果明显好用了，可能就是开机键长时间使用后磨损得接触不好了。

排版是技术活，不管有没有首行缩进，只要让我看得舒服我就能接受。

我猜题主想说的是”推荐“。

关注功能更多是以用户为主导的，而推荐功能更多是以平台为主导的，社交平台上没有关注功能不会导致流量经济的破灭，因为流量只是个中间关节，最终目的还是把流量变现，比如把所有关注功能都移除，但每天被平台推荐的号，依然能有很强的带货能力，甚至因为没有了关注功能可以直接抹杀那些不符合平台推荐策略或不买推荐位的号，导致平台进一步垄断这个市场。

人们通常会使用关注数量来对一个号的信誉、内容质量等进行预测，也就是说人们通常会相信关注数量越高的号就越好，至少大多情况下是这样的，否则不会形成这样的意识。
但就有些人会利用这一点来作弊，刷关注量来提高人们的预期，来获得人们进一步了解的机会。
这个就好要分开看了，关注功能本身是没有错的，有错的是作弊行为，整治的重点也应该是这些作弊行为。

我游戏电脑放卧室里，晚上睡觉开着会吵，扔别的屋子里就没法在卧室里打游戏。

我以前有台 NAS ，扔别的屋子里，除了做文件存储以外，还跑了一大堆东西，可能配置不够高，或者限制没做好，会互相抢性能，比如跑了个 AI 程序之后，文件存储功能也卡得没法用了。还有，姑且不说压制 Windows 的自动重启更新需要好一番折腾，不知道是不是因为没有用 ECC 内存，还是说非 Server 版 Windows 是不是在稳定性上有啥缺陷，跑时间长了就会遇到莫名其妙的问题，通常重启能解决。

后来我就想性能、故障隔离，当然也跟我的用途需求有关，我决定专机专用，NAS 就老老实实干存储的活、软路由就老老实实干网络的活、服务主机就老老实实跑服务，哪个有问题就收拾哪个，不需要一停全停。

当然，每个人每个时期的需求都是有区别的，而且不同的需求和问题的优先级都是因人而异的，有可能我不能接受的你可以接受，或者你不能接受的我能接受，我只能说拿 PC 跑 NAS 肯定是可以跑的，就看是不是符合你的需要。

@MEIyiyi #4 file 协议？也就是说用浏览器自带的 PDF 阅读器打开本地的 PDF 文件？你想用 JS 控制的话是打算把 JS 写在哪呢？

软 RAID-1 是 RAID 方案，ZFS 是文件系统方案，这俩不是一个维度上的问题；比如 ZFS 也有 RAID-Z0 、RAID-Z1 、RAID-Z2 、RAID-Z3 ，如果你换了 ZFS 却用的是 RAID-Z0 ，那还不如以前的软 RAID-1 可靠。

我重度使用过 Ext4 和 Btrfs ，ZFS 据我的了解就是提供了一些性能优化和快照之类的实用特性，服务器用的主流文件系统可靠性都差不多，实际上存储可靠性方面文件系统是很低优先级去考虑的，更高优先级是：
1. 机房所在整个地区电力或网络故障了怎么办；
2. 整个机房故障了怎么办；
3. 整台服务器故障了怎么办；
4. 整块硬盘故障了怎么办。

前面那些问题解决了之后，基本就解决了 99%的可靠性问题。