还有个方案，就是外接电脑，用 HDMI 连电视播放，你看看是不是电视面板或者芯片机能不够。

如果证明面板和芯片没问题，那就看看是不是解码器和片源的问题。

国内视频网站的清晰度没有统一标准，而且虚标严重，另外视频发布者可能是以 1080p 的片源拉到 4K 再上传的，本身就是糊的。

晒太阳的目的是把胆固醇转化成维生素 D ，如果你口服维生素 D 的话应该就不是很有必要特意去晒了。
岁数大恢复慢可能是身体多项机能老化的结果，补钙补多少最好还是遵医嘱，过补有增生风险。
另外康复训练也是有必要的，一方面是恢复灵活性，另一方面让新长好的骨骼更密。

AppleID 没转外区的话，数据都在云上贵州，也就是境内，根据各种法律同样是受到监管的。

你可以转区到境外，不过可能会影响手机上的本地化服务吧。

一般来说只要不涉及刑事犯罪，国家就肯定不会把本来就紧缺的侦查资源浪费在你身上，不过既然你做出了当前这种判断，就说明这个理由可能说服不了你。

顺便说一句，我国的侦查能力是世界上最强之一，在境外干违法的事情，只要你肉身还在国内，大概率会落网（比如干菠菜、诈骗和搞颜色的），所以真那么敏感的话，还是考虑肉翻吧。

PHP 的那个注入问题可能和 MongoDB 无关，是 PHP 自己语言特性导致的，字符串被错误地反序列化为 PHP 代码并执行。

Go 是编译型的语言，源代码编译成为了字节码，而运行过程中如果不提供编译能力的话，也无法把字符串入参编译为 Go 字节码并运行。

一些脚本型语言如 Node.js 中采取了另一种安全机制，即必须使用 evel 等特殊 API 才可以将字符串作为程序运行。

大多 Linux 终端模拟器都是用的的 Ctrl+Shift+v 来进行粘贴操作，不过这个就是个普通快捷键，大多情况下是可以配置的，你可以在终端模拟器的快捷键设置里看一下。

“喔（ wō、ō）”是多音字，用来指代韵母“o”不够精准，因为可能会有人用“wō”这个读音，带着声母就容易让学生理解有误。
“欧（ōu ）”是复韵母“ou”，用来指代韵母“o”应该是完全错误的。

如果想用用汉字来指代韵母“o”，最好是在权威的字典中找没有声母且任何情况下读音都在“o”的四个音调+轻声的范围内的字，我目前手边没有权威的字典，在网上查了查，可能“噢”这个字会精准一些。

回过神来，觉得用汉字来指代拼音本来就是个本末倒置的事情。
用汉字来指代拼音可能是有历史原因的：
1. 基于种种原因综合考虑，国家需要制定一套统一的音标系统——汉语拼音；
2. 初期推广汉语拼音需要让人民快速地了解到拼音的读法，便借用某一地区的读音中的某些字，来让人们直观、快速地了解到拼音的读法；例如“o”当时可能就是选取的“喔”，但是当时“喔”这个字还不是多音字，仅有一个读音“ō”。
3. 一旦汉语拼音得到普及了，那么就应该进一步标准化，废止借用汉字来说明读音，进而以口腔的姿态、发音方法等来说明读音。

其实重复查两次的的问题还好，顶多是浪费一部分数据库性能而已，不会导致 bug ；目前的实现是有可能产生 bug 的，即在高并发场景下 createOrder 执行的时候不一定确保 item 一定存在，假设 item 有可能在“const item = await Item.findOne({ where: { id: body.id } })”执行后、“createOrder”执行前被其他进程的业务逻辑删除，那么此时 createOrder 就会在 item 不存在的情况下执行；若 createOrder 内部做了 item 的存在性验证，此时会抛出异常；若未做 item 的存在性验证，则会产生脏数据。同理 createOrder 内部的多项数据库操作如果不能确保事务性（原子性）的话，也会有同样的问题。

针对题主的例子来说，item 的存在性验证仅为 createOrder 的顺利执行而服务，那么可以把这个过程并入 createOrder 内部，在 createOrder 内部查询 item 不存在则抛出异常，同时使用事务确保多表操作的原子性。

保障用户知情和同意，所以理论上只要涉及到用户可能未知情、未同意的情况下都要弹，同理，如果充分确保用户已知情、已同意的情况下可以不弹。

说人话就是注册和登录的环节弹，隐私政策有变更也要弹。

核心思路就是能统一的都统一版本，不能统一的彻底分开。

代码分两个 repo ，核心+应用。
核心提供底层、基础、通用的接口，尽量向前兼容。
应用调用核心接口来实现业务，可以针对不同客户的需求分不同分支。
多个客户在应用方面有交集的话，可以再分出一个中台 repo 出来，只维护通用的应用。
构建的时候是使用核心+中台+客户分支一起编译。

一个新的应用功能先在本客户的分支上开发，当具有通用性之后就分离出来放入中台，同样当中台硬用不再具备通用性之后就从中台拿出来放到客户分支上。
应用开发过程中发现需要某核心不具备的基础能力，则可以向核心提扩展需求，核心维护团队评估合理后进行开发。
每次发版，按照客户和版本号打 tag ，这样可以通过客户信息来定位到当前服务器上部署的代码版本（历史版本也可以定位）。

首先得明确，这是个技术债务，不还的话利息越滚越多，还债的成本可能低于不还债未来导致的不必要成本，所以最好尽快解决。

其次是，要对产品需求进行有效管理，至少每一次的需求内容都要有记录，然后梳理出每个客户的最终需求和产品设计方案，然后根据基础的代码来看缺什么、需要修改什么，最不济的方案就是根据最新需求从一个旧版本重新开发，有时候会比 hack 现有代码要更快。

理论可以正面论证，也可以反面论证，从多种角度论证往往可以获得更加全面、客观的理解。当正反论证结果一致的时候，说明结果是有一定必然性的。

比如现在风力发电都是集中发电，没有分散到每家每户，可以探究一下有哪些可能的原因。

另外可以核实一下所了解的信息有没有偏差，比如幸存者偏差、失败者偏差，这个可以从基数去看概率，就像核电，全球历史上有多少座核电站，出事故的有多少次，有几次是影响人类安全的程度，未来是否有改善。

可以在 Windows 下跑 Linux 虚拟机，用完整虚拟机方案或者 WSL 都可以，我曾经用 Windows+Virtual Box 的方案一年的时间，白天全屏虚拟机做开发，晚上把虚拟机暂停回到 WIndows 上玩游戏。

Proton 应该是 Linux 下游戏的最佳方案了，如果这个都没攻克的游戏，你自己折腾也不一定能搞定。

曾经折腾过 PVE ，最终卡在显卡直通，因为 NVIDIA 是禁止在数据中心里用游戏卡的，所以显卡驱动会自动检测当前是否在虚拟机里，如果在的话显卡驱动就会拒绝工作。存在那种魔改版显卡驱动可以绕过这个检测，但我是不敢用。

玩游戏就用直接方案痛痛快快玩，搞些小众方案很可能会让自己不快。

也是之前好久没玩了，最近跟家人在 Switch 上用电视同屏玩。
可以参考这个 https://minecraft.fandom.com/zh/wiki/%E4%B8%8B%E7%95%8C%E8%A6%81%E5%A1%9E?variant=zh

在东西方向找可能好找一些。

我自己是做了个 Shell 工具箱，把实用的脚本放在里面，在各个环境里一键安装，就可以使用这些工具了。

网上喷子那么多，联系越麻烦就越安全，有些项目甚至连 Issues 都关了，有问题只能 PR 提交复现问题的测试用例。

你不可能让所有人满意，所以不用往心里去。

但个人建议，商业项目就走商业路线，按合同一手交钱一手交货；走赞助就纯赞助，不给任何增值服务；对用户来说不会有一种付了费就能获得商业支持的错觉，对自己也不会有一种没付费就是白嫖的不平衡。

感觉这玩意还在炒作期，等到冷静期再说。

这个跟屎山没有关系，只是指导合理抽象的一种思路，避免不合理的抽象导致各种代码维护问题。

我试着举个例子吧，如果不贴切就当抛砖引玉了。

“modification”式的做法：写一个 class ，叫做“动物”：
有一个属性叫做“物种”，枚举为“狗”、“猫”；
有一个方法叫做“叫”。
“叫”方法里写一个判断逻辑：当“物种”为“狗” 的时候，输出“汪汪”；当“物种”为“猫”的时候，输出“喵喵”。
后面需求发生了变化，想要增加一个新物种“鸭子”，那么只能够去修改“动物”这个 class ，在“物种”这个枚举里添加“鸭子”，在“叫”这个方法里添加一个新的判断分支，当“物种”为“鸭子”的时候输出“嘎嘎”。

“extension”式的做法：写一个 interface ，叫做“动物”：
有一个属性叫做“物种”，
有一个方法叫做“叫”。
基于“动物”实现一个“狗”class ，“物种”属性为“狗”，“叫”方法为输出“汪汪”；
基于“动物”实现一个“猫”class ，“物种”属性为“猫”，“叫”方法为输出“喵喵”；
后面需求发生了变化，想要增加一个新物种“鸭子”，可以在不修改“动物”代码的基础上直接基于“动物”实现一个“鸭子”class ，“物种”属性为“鸭子”，“叫”方法为输出“嘎嘎”。

试试在 graftcp 后面套一个 privoxy ，用于按照域名规则分流。