有个说法是“抛开剂量谈毒性都是耍流氓”，这个其实也适用于环保，是否造成污染不是说一个地方有没有什么物质，而是这种物质浓度达到了什么程度。

现在普通干电池都有强制生产标准，比如不允许添加汞，使得随生活垃圾一起处理不会造成污染。

即便电池内本身还是含有一定量的有害物质，但被更多量的无害生活垃圾稀释后可能就不会对环境产生什么危害。

不买，太大了，比 Note 20 Ultra 还大，没有强拍照需求的话完全没必要。

然后 S21Plus 屏幕分辨率和 S21 一毛一样，我用 S9 的高分辨率小屏幕习惯了，看 S21Plus 会觉得不够清晰，于是我最终买了 S21 。

用了几个月感觉没啥大问题，不过跟 S9 比起来软硬件体验都差了一些，贴钢化膜会导致屏下指纹难用，我倒宁愿用背面指纹识别的设计，不过能用上新的 Android （ SAF 之类的新特性），也就忍了。

@yasumoto #10 小米就是性能不大好，广告比较多，能忍受的话勉强用个一两年就淘汰也还好。

因为我没有搬家的需求了，所以买了索尼的电视，主要就是冲着没有广告，国产的盒子和电视广告问题比较让人头疼。

其实如果不是一定非要用电视应用的话，接电脑看片也可以，至少看一些下载的资源比较方便。

小米的用了一年，目前还没啥问题。

然后小米的代工厂自己有个品牌，据说比小米的性能好一些。

有 RO 反渗透的比较大的牌子应该都可以，注意出水速度和废水率。

然后就是算滤芯的价格摊到每天平均多少钱，看自己是否能接受。

@yasumoto #6 用显示器的话，你可以买个盒子，能网络出国的话买个 Google TV 设备还挺好用的，也可以接个 HTPC 。

互联网品牌不保证影像品质，比如极米（不知道这牌子还活着呢没有）之类的，几千块钱就勉强能用吧。

影像品质好一些的就是老牌做投影的，比如爱普生之类的，但可能需要幕布来呈现。

投影实际上也是一个上不封顶的坑，追求效果的话机器和幕布之类的一套也可以很贵。

有条件买电视吧，除了搬家不便携以外性价比还是比投影好一些。

猜测是直接检测应用层的协议名，不管是啥端口，只要检查到 Web 协议就不行。反正这个从技术上来说是很容易实现的。

我现在的方案是用 OpenVPN 或者带加密和伪装的隧道程序，来进入家里的网络环境，然后再访问家里的各种服务，一次性配置好了平时用也不麻烦。

v2 （那个软件）的路由功能挺好用的，可以让一部分域名或 IP 走特定路线。

商业公司的核心目标就是盈利，所以私以为“以客户需求为中心”的思想从来都没存在过。

要是真的存在过，也一定是因为公司的盈利与“客户的需求是否被满足”强相关，最“中心”的一定还是公司的盈利。

如果你觉得你不需要业务经验，可以不用管别人怎么说的。

如果你已经搞明白了什么是“业务”，那么你就自然而然知道了朝哪个方向去探索如何沉淀和积累经验。

简单来讲，你去了解一下产品经理在做什么工作，他们在思考什么，这些全都了解了之后你基本上也算是对业务有一定的了解了。

https://aplayer.js.org/#/

我用的这个，自己简单写了一段前端代码，通过解析 Nginx 提供的 autoindex 页面来拿到音频 URL，然后用 aplayer 播放。

你要是没有手动直接用 autoindex 页面的需求的话，Nginx 的 autoindex 有一种 json 模式，对程序更友好一些。

这个音频播放器的作者还有视频播放器的库。

不过你要知道，浏览器支持的媒体格式是有限的，也可以看看 kodi 、plex 之类的方案。

从外因的方面来说：每个人的 25 岁都是不一样的，比如出身富裕家庭的 25 岁的人想没有存款 /不动产都难，但出身贫穷且家里入不敷出的 25 岁的人不大可能有真正意义上的存款。

从内因的方面来说：每个人的财务规划也不一样，很多人存款是有未来大额支出的计划，或者为了保障，如果愿意借贷以及买了保险有了最够的保障，也就没有理由存款。

仅仅用年龄来衡量应不应该有存款是显然是极其片面的（就像仅用时间因素来判断速度，而忽略了路程因素），但对于很多自媒体来这种“简单的真理”往往能带来较高的流量，说白了和标题党是差不多的套路。

信息不一定都是有用的。

可以改 package-lock.json 来临时升级，部署的时候用 npm ci 而不是 npm install，npm audit fix 和 GitHub 的漏洞扫描应该都是用的这种处理方案。

然后轮子长期不维护或者明确表示不愿意升级依赖，就自己 fork 一份，然后改依赖，提 PR，主项目合并 PR 之前在 package.json 里用自己 fork 的版本。

随机生成的，用了一个叫做柏林噪声的算法，每次开局生成一个随机种子，然后柏林噪声生成宇宙的各种参数。
柏林噪声算法的特性之一是，你用相同的种子一定会生成一样的宇宙，这也就允许你拜访一个太阳系之前可以先不生成那个太阳系内部细节。

你需要一个 Sandbox，Worker 的功能虽然有一定的限制，但是远不及 Sandbox 的那种程度，一旦运行脚本就意味着 Worker 能调用的所有 API 都可能会被调用。

你可以看看 Deno，它的产品定位就是一个 Sandbox，我没用过，也一直觉得它“未来会取代 Node”的宣传很扯淡，但至少 Sandbox 的老本行可以一试。

或者你可以去研究一下其他的 Sandbox 方案。

另外你也可以考虑用容器之类的封装一个专门用来跑不确定安全性的脚本的实例，用有限的 API 跟主应用程序互操作就行。

西数红盘是叠瓦盘，介意的话就用希捷酷狼。

要不要自己折腾，取决于你的技术能力和你平时有多少时间，我是自己折腾的，主要是因为我的需求比较多（奇葩），而且我自己有十几年的 Linux 使用经验。

如果没有底气能折腾得比商业化的产品更好，或者没多少时间折腾，还是建议咬咬牙上商业产品吧，比如群辉。

NAS 有个好处就是可以 7x24 小时跑，但如果你只是想可靠存数据不需要全天候跑的话，台式机上插 2 块硬盘做 RAID-1 也挺方便的。

ES 和 MongoDB 的而应用场景不一样，定位也不一样，各自擅长和不擅长的事情也不一样。

ES 不是数据库，没法保障数据一致性，因为存在刷新周期，所以你读取的数据总是上一次刷新的数据，如果在此期间有任何数据变化，你是拿不到最新的数据的，只能等下一个刷新周期。强一致性需求是数据库的强项，你查询 MongoDB 不可能返回一个过时的数据。

传统业务数据库的索引机制有个限制，就是索引越多写性能越差，而且每一条索引都有很高的专能性，所适用的查询场景极其有限。举个例子，后台一个表单有 20 个查询字段，用户会随机选取其中任意数量的字段组合查询，每种组合出现的概率相当且要求查询速度都要很快；如果用业务数据库设计索引的话，理论上可能需要 20 的全组合那么多的索引，都别说 20 的全组合了，常见的业务数据库一个表上有 20 条索引就很让人头疼了。这就是搜索引擎的用武之地了。

MongoDB 有一个 Change Streams 的机制，可以用程序监听表数据变化，这个机制可以用来同步 MongoDB 的数据到 ES，于是数据的写操作和强一致性读操作都在 MongoDB 上进行，不要求一致性的读操作（比如后台报表查询可以容忍几秒的数据滞后性的话）可以到 ES 里查。

现在是全球化的时代，大多产品都不是绝对完全在一个国家生产的，软件领域更甚。

Linux 的代码贡献者中有相当多的中国开发者、企业、研究机构，是全世界贡献者共同工作的成果，直接入股变成成员其实也从某种意义上算是实现了国产化。

以中国的技术能力来说，直接在现有的 Linux 源码上开自己的分支是没啥问题的，但没必要，因为需要开的话随时都开得了，也就不存在什么技术封锁风险。

个人的经验来看，LTS 最好时刻保持最新，因为 LTS 的更新都是增强可靠性和安全性的更新。

不过我在公司核心项目上一直在用 Current 版本，也是时长会更新，品控做得还不错，很多年来没遇到什么问题。