对于需要频繁操作子文档的场景，应该把子文档抽出来做成一个新的 Collection，然后用 ref 和 populate 来与 PostCountry 建立关系。
@
tctc4869 Minecraft 有命令方块，创造模式下自己搭建建筑，用命令模块写游戏逻辑，可以做出一个带剧情流程的 RPG 来。
真随机数的技术已经很成熟了，现代系统大多都提供了真随机数生成器，特别是操作系统。
举个例子，Linux 操作系统上有 /dev/random 和 /dev/urandom 两个随机数生成器，感兴趣可以去查一下相关文献，简单来讲就是会检测计算机运行过程中的一些“噪声”，比如时间、IO 响应时间、外设信号变化、键盘敲击时机、鼠标位置变化，甚至是磁场波动，不同系统（发行版）、硬件环境能提供的“噪声”来源不同。
JS 的 Math.random()没有规定底层实现细节，由各个 JS 引擎自己决定如何实现，最省事的方式就是直接调用系统的随机数生成器。
简单理解的话：函数后面加括号就是调用函数的语法，第一种是在 await 后调用，第二种是先调用再用 await 接收结果。所以第一种是等前一个 timeoutPromise 执行完返回结果后再调用执行下一个函数；第二种是三个函数依次开始执行，执行的过程是同时进行的，在 await 部分是等待前一个执行完返回结果后才等待下一个执行完返回结果。
“存到变量”不是本质影响这个过程的因素，而是一种表象，本质是你的异步函数什么时候被调用的。可以去看看 Promise 的执行过程，await 一个 Promise 对象就是现在有结果就现在拿，现在没有结果就等着结果出来，结果出来拿到后再继续往下执行。
国内游戏都要审批才能发行的，国行作为正规渠道的商品是被强制规定只能安装审批通过的游戏的。
国际版 Switch 不受国内部门监管。
买国行游戏机就是得有预期：游戏审批是很漫长的过程，可能国外过气了国内才刚审批通过；而且很多你觉得很正常的游戏很可能无法通过审批；或者游戏改得面目全非才能最终通过审批。
如果你想玩的游戏在国行主机上都能玩得到，且你能接受游戏本身所做的改动，也可以考虑国行机子，但就是未来新出的游戏不一定也会来到国行主机上。
没有明确需求就直接选型是大忌。
如果只是开发一些简单的交互页面的话，原生 JS 足以，document.querySelector()和 document.querySelectorAll()搞定元素选择，Element.classList 、HTMLElement.style 搞定样式变化；如果觉得用 fetch 麻烦的话，顶多加一个 Axios 。
建议以 WebComponents 的方式写，日后需求复杂了想引入框架会比较方便。
前端开发的知识可以去 MDN 上看，大多都有中文教程。
“先吃再付费”一般发生的情景在于堂食，外带、外卖、电商未见后付费模式，而堂食的“先吃再付费”提供的是一种服务保障，不是定价权，实际上以个人人生经历来看，通常只有在用餐中发生严重问题才可能影响最终付费的金额，比如菜里有虫子，解决方案基本就是退掉或重做。而且因为是堂食，顾客人身在餐厅控制的场所内，吃霸王餐的风险较低；外卖采取后付费策略的话可能会更容易出现故意逃单的情况（一些楼也提到了人性本恶的观点）。
而消费者掌握定价权往往存在于赞助（打赏、捐助）的情景，比如街头艺人唱了首歌，觉得值多少就给多少，觉得不好也可以不给。
所以从线上内容的特点来看，与“先吃再付费”的前提情景有较大差距，采用相同思路的话可能与预期不一致的风险较高。楼主可以回味一下。
从前段时间外卖风波可以感受到，自动化系统的算法难以精准覆盖绝大多数实际情况，所以一方面会存在无法妥善处理的特殊情况，另一方面也可能会出现 Hack 指标的情况；这个是需要慢慢打磨长期完善的。一篇内容对不同人的价值可能不一样，不能简单从宏观统计情况来预测微观个人行为，需要给用户做画像，给内容打标签，画像和标签做得足够精细，才能足够准确地对用户行为进行预测，参考个性化广告推荐、短视频推荐等行业。楼主帖子里的判断规则实际上也是推荐算法的一种（只不过就是从能不能付费变成了该不该付费），在当今的推荐系统行业中算是最初级的水平，不过相信楼主只是给出了一些大体方向，而不是最终的方案。
剩下的就是运营模式。互联网产品往往会关注这几个节点：新增、留存、付费转化。对于楼主的论坛来说，本身也算是一个带有盈利性质的互联网产品（除非楼主想搞公益社区），那么新增作为第一道漏斗，如何在复杂的规则、较高的注册成本的同时吸引用户，是需要好好考虑的。另一方面，作者会以收益为导向选择发布平台，而收益取决于读者的数量和平均质量决定，读者的数量和质量由内容质量和数量来决定，从而形成一个读者促进作者、作者促进读者的循环（参考 PT 社区），在读者和作者的质量基本相匹配的条件下逐渐提升整体的规模，任何一方过高或过低都很容易导致这个稳定状态崩塌（除非有较多的资本可以进行调控）。不过和常规的互联网产品相比，这种新型知识付费平台的新增、留存、付费转化更多受控于平台自身的循环，平台本身进行调控的余地不多，需要更多的运营手段的支撑。
建议楼主多进行市场调查，多研究些案例，以便对自己论坛的运营数据进行客观的解释，帮助更精准地调整运营模式和策略，这种产品要想做到较大规模可能是一次长征。
可以拿 express 学习，需求稍复杂一点可以考虑用 koa 。
商业驱动的开源，最成功的的是 Google 的 Chromium 和 AOSP，明面上“开源”，背地里帮助 Google 的商业业务处于垄断地位。这种项目的特点是源代码你随便用，但主线的发展趋势由母公司说了算。
开源商业化最成功的的是走基金会赞助模式，如 Linux 基金会。他们的项目的特点是谁都别想凭着代码本身赚钱，但捐钱可以让你省很多开销。
像 RedHat 这种以前卖服务很吃香的现在都被云打得够呛。
开源就意味着收益和代码本身没有多大关系，所以开源协议基本只是辅助作用，一个项目的可持续发展，要靠专业的管理和富有远见的市场战略。
北京联通。
一分钱一分货。
魏丕恩不知道指的是不是出国，要是出国的话得看机场稳不稳。
游戏如果是连官服的话没问题，但要是互连对战的话不同地区的不同运营商线路情况不同，比如北京联通连温州移动就卡的要死。
1. 看你看什么画质了，通常来说硬解能效最好，主要靠 GPU 里的解码器，软解才需要性能很强的 U，前段时间研究的结果是 4K HDR 可能需要中高端的显卡，如果只是看 1080p 的话现在大多核显都没问题。
2. 寿命瓶颈主要在硬盘，但是只要不是频繁读写和断电通电的话对硬盘寿命影响极小，除非遇到次品。
3. 因为同批次硬盘容易同时坏，以及因为重建时间可能会很长，期间再坏一块盘的概率较高，所以一般不建议用 RAID-5，建议用两块及以上冗余盘或超出冗余上限也能读取文件的方案，如 RAID-6 和 SnapRAID 。买硬盘也不要一起买，或者换新的时候不要一起换新。一定要定期跑快速 S.M.A.R.T.检测和慢速 S.M.A.R.T.检测，我现在是每天一遍快速检测，每周一次慢速检测，有问题立即报警。
4. 一般在系统文件管理器里挂 SMB 或 FTP 就直接用就行了，用户、分组、权限啥的你一个人配好就行了。除非你有别的功能的需求，这个可以具体提出来。
5. 要想静音就得减少发热量，也就是看低功率 CPU，像群辉用的就是 Intel 的 J 系列 CPU，功率 10W，随便一个低速风扇就能压得住，你要是自己攒的话可以看这种 10W 的 CPU 。风扇可以用 20cm 的大风扇，风量足够的条件下转数低，相应噪音就会小。
不想折腾直接咬咬牙上群辉，商业产品体验做得好。
想自己折腾的话，我一年前自己攒了一个，华擎 J4105 ITX 小主板+CPU （如果主板不够 4SATA 可以找店老板加个 PCI-E 通道转 SATA 口的转接），迎广 MS04 四盘位小钢炮机箱（带电源和 1 个 20cm 大风扇），4G 内存，一共花了 1800，性能比群辉的 2500 元的机型还要好（群辉貌似还不包括内存），CPU 用的是同系列所以互相兼容。可以让卖主板的淘宝店家给预装黑群辉，但是我喜欢开放性自己装了 OMV，为了方便就把系统装在一个 16G 的 U 盘长期插在机器背面，目前运转良好。硬盘要是不喜欢叠瓦盘就上希捷酷狼，比西数红盘要贵，但红盘一般都是叠瓦盘，其实个人认为只要没有频繁写需求的话叠瓦盘的缺陷是可以忽略的。你要是自己攒可以看一下因特尔是不是除了新的能效更好的 J 系列 10WCPU，一般华擎会对应出板载套装。
J4105 功耗 10W，带核显，核显解码 1080p 完全没问题，4K 不行，但你可以不用 NAS 来解码，用电视或者投影仪自带的系统来解码，这样你只要搞定磁盘 IO 速度以及网络传输速度就 OK 了。
我自己用的 SnapRAID 的方案，3 数据盘+1 冗余盘，类似 RAID-5，但是即便多块盘有坏道也不影响好的磁道上的文件，自己用需要一定的 Linux 使用经验，以及不怕折腾。另外我配合 SnapRAID 使用 MergerFS，把多块硬盘虚拟成一个文件系统，但又使得每块硬盘可以独立使用，进一步提升数据在极端故障下的生存率。
我现在除了存文件以外； NAS 上还跑了 Docker，Docker 里跑了 Pi-Hole 、Gogs （轻量级 GitLab，非团队使用完全足够）、一些杂七杂八的轻应用；自己写了个 Systemd 配置文件跑 Aria2 的下载器，可以用 Web 或 Android 端控制（但说实话个人觉得任务管理方面不如 Transmission 好用）； OMV 本身提供各种 NAS 基础功能的 GUI 配置能力，就像群辉那样。
我是让运营商把我的光猫调成桥接模式，有公网 IP （虽然是动态的），然后我自己有一台华硕的路由器，路由器自带 OpenVPN/PPTP 和 DDNS 服务，处于安全考虑，我现在在外面都是通过 OpenVPN 经由 DDNS 的域名直接连进家里的局域网，再访问 NAS 的，还算方便吧，若是能承受安全风险的话直接用路由器的端口映射把 NAS 暴露到公网上也是可以的。
投影分互联网产品和专业产品，所谓互联网产品就是极米之类的，不推荐坚果（不知道这牌子还活着呢没有），专业产品如爱普生。
投影的质量由投影仪和幕布共同决定，如果你仅满足于能看到画面，就直接买互联网产品以及直接投在墙上就行了，但若追求品质的话，就只能去看专业产品以及专业幕布了，这块是个大坑，不光参数多，价格还贵。
需要频繁进行文件操作，GUI 肯定是最方便的，其次是将远程文件系统 mount 到本地，再次是使用 scp 、rsync 之类的指令。
如果本地有桌面环境的话，Linux 可以用桌面自带的文件管理器直接走 SFTP 连目标服务器，Windows 和 MacOS 可以用开源、安全、功能齐全的 Cyberduck，或者不在乎捆绑商业性组件就用 Filezilla 。
直接 mount 的话可以考虑用 SSHFS 。
SQL 的核心用法就是拼接字符串，所以其注入脆弱性是天生的，因为其只做到了语义上的结构化并没有做到格式上的结构化，用法就是拼接 SQL 字符串，所以很容易破坏掉预期的语义结构。JSON(YAML)、XML 等格式因为本身可以很容易对象化，对对象的操作是被限制在对象提供的模式内的，所以天生具备对注入的抗性。
只要你前后端严格按照 JSON 格式来处理数据，不在序列化后进行字符串拼接，通常不会有注入风险。
剩下的就是不管用什么都要做好的安全策略，比如限制好查询的数据量避免全库导出。
我看邮件怎么写的是商业授权呀，个人授权是不是用不了。
关键看 1024 是不是仍然买一送一。
看不看文档和能不能看懂文档是两个问题。
很多人问问题的时候往往是没有看文档，大佬不希望你直接问“为什么 Vue 里 onclick 调用 method 无效”这种问题，因为凡是认真看了文档的人都不会问这种问题，当这些文档都明显能解答的问题问的人多了大佬自然会觉得烦。
看不懂文档说明更基础的知识没有掌握，那么这时候可以直接问文档里的某一段或某一个词是什么意思，大佬会告诉你应该先去了解哪些知识，等你按照大佬说的做了了解了必备的知识，自然之前看不懂的就能看懂了。只有好心人才会授人以渔。
第三方回调的时候是否有他们的回调 id，有的话可以在存储回调数据的表里将这个 id 标为主键或唯一索引，然后每一个回调请求过来就尝试执行插入操作，失败就放弃这个请求，成功就继续调用业务逻辑。
为了防止服务刚 insert 成功就挂掉导致业务逻辑没有正确执行，可以在回调数据记录里加一个处理状态，处理成功就更新状态为成功，那么在服务重启的时候可以先去查一下有哪些未处理完成的记录，重新处理即可。可以用事务来保证数据库多次读写的原子性，避免由于程序中断或分布式处理导致的脏数据。
如果你处理回调请求的时间比较长，那么也可以用消息队列，收到第三方回调就把回调数据插入到消息队列，插入成功就立即返回给 第三方成功，这样第三方就不会持续给你发回调。后面的集群以适当的负载匀速消费队列里消息即可。
源码交出去就没法控制了。
所以要么卖二进制可执行程序；要么就源码卖断，买家随意处置。
开源软件的许可方面是法务确保消除侵权行为，要是没有法务保障开源许可证就是一张白纸。
像甲骨文、微软、Adobe 等企业基本上就放弃 DRM 路线了，只要法务强大到能解决侵权问题就可以（顺便捞一波赔偿）。
所以 deno 的定位是个 sandbox，不是一个 runtime，你对比的 python 和 node 都是 runtime，安全方面可以靠 Linux 权限机制和防火墙来搞定，套个容器也就是个 sandbox 环境了，而且即便你用了 deno 也都离不了这些安全策略的。
以后要是用 deno 开发服务器端应用，跟 node 的区别基本上就是得多一步开权限的过程，权限是基于能力而不是基于功能的，所以你只要开了网络权限就无法靠着权限控制机制抵御任何网络攻击了。
相应的，不管在浏览器端还是在服务器端，如果真的有运行任意脚本的需求（比如算法刷题网站或编程学习网站等），可以把脚本扔到 deno 环境里执行，将运行的输出再拿到安全环境里使用。
虽然容器也能做到这一点，但一方面 deno 会更轻，另一方面 deno 能跑在浏览器上。
公网 IP 确保能从外网访问到，没有的话找运营商要，不给就投诉；
DDNS 就是动态绑定一个域名，你从外网用域名访问，确保公网 IP 发生变化依然能访问到。
访问你的服务器有两种思路，一种是端口映射：在路由器上设置端口映射，使得从公网上访问到你的路由器的特定端口直接转发到你的内网服务器的特定端口；
另一种思路是用 VPN，我家用的华硕路由器自带 PPTP 或 OpenVPN 服务，可以让外网的设备通过 VPN 线路成为内网的一个虚拟设备，然后像在家里一样访问内部服务器。
Select Language