好几个月前有了。欣赏不来 G 家的审美，还有 Gmail 的那个 [写邮件] 按钮，觉得真丑

一个剧本（小说）能找到好几个视频。前期看着爽，后期就拉了。
有的视频做的还不错，不过剧本后期拉，救不回来。也有中途断更的，估计是观看量下降。
没看到有收费的，倒是有插播广告的

@MinonHeart 有点不友好

用插件生成了一个测试文档，里面包含 jb 的 js ，有点友好。
文档结构还是挺好的，可以拖拽调整层级，很方便

最后一个运营商名称怎么搞上去

强手段：限制经济来源
软手段：教育父母。要和父母多交流沟通、引导，如果他们对这些真的感兴趣，建议给他们科普下基础知识以及风险。好比这个投资赚钱，为什么他们不自己赚而要拉上你呢。这样能够让他们在后续类似的事件中，可以自行处理这些。在娱乐上也给予正确的引导，免得他们闲着就想这些事情。
自己：身份证这类重要证件非必要情况下不要给父母，实在需要也应问清原因。经济控制在自己手中，每月给生活费这种方式会比较好些。多和父母朋友沟通，你在这里发这些，大家只能给你建议，还是需要你自己去解决实际问题

@TerryNi 离谱，我的 320 多次，剩下 82%

https://www.hub.moe/laboratory/onedrive-direct-link.html
分享下 Automator Application(macOS) 脚本

@george2077 很合理。

当前架构是 View 初始化后，任何地方都访问不到。按这样改得变更架构了

@shalingye 记得当时有创建一个 smb 快捷方式

@mmdsun 是内网 IP

@GiantHard #5

> js 和 ts 混合项目，TPR 怎么处理？

最初可能想偏了，想用 TPR 来担任 js 、ts 的编译和 cache 。只用于 tsc 加速确实没什么问题

> TPR 项目中有引用图片/SVG 等这些二进制资源怎么处理？

这和上个问题有关联，按你的描述我们的用法不一样

> TPR 在 watch 和 build 上有很大的优势吗？

按我们的项目来说，类型检查占用总构建时间的比例约为 1/3 ，本地跑不划算，不清楚 TPR 能节省多少时间。官方这点说的没错，但是没看到很明确的数据。构建工具也是使用 cache 来提升构建速度，如果去除类型检查（让 CI 来做），理论上构建速度是相近的，因此后续也没有做这方面的调研了。

> TPR 中不同项目导出同名类型会导致类型错误

可能是和第三方库的类型冲突，也可能是我们自定义的全局类型冲突，刚出时候做的调研，具体记不清了。

> Nx 管理工具和 TPR 感觉功能重叠了，同时使用导致项目结果太复杂了

两边都是通过 cache 提速的，另外 TPR 的项目依赖需要手动编写（ tsconfig.json ），和 package.deps 重复了，维护不会很麻烦吗？（有看过一些同步的工具，但是还是挺麻烦的）

----
额外想到几个问题：

1. js 和 ts 混合项目，TPR 怎么处理？

调研时候，是在 js 项目中增加一个 ts 入口文件，暴力但确实能用。

2. TPR 项目中有引用图片/SVG 等这些二进制资源怎么处理？

当时想到的是：

2.1 Copy 到 dist 目录，但是这样 TPR cache 对二进制资源也就不生效了（理论，没有实践过）

2.2 生成的 js 、dts 和 ts 在同一层级，这样不方便管理

3. TPR 在 watch 和 build 上有很大的优势吗？

没有实践过

1. 文中提到的时间，真的不算长
2. commit hook 中执行类型检查，时间确实长了，不合理。我们的做法是放到 ci 中，本地不做构建时类型检查，由编辑器提供
3. TPR 中不同项目导出同名类型会导致类型错误，不知道这个你是怎么解决的？
4. 另外，Nx 管理工具和 TPR 感觉功能重叠了，同时使用导致项目结果太复杂了

😅应该去游戏网站

Menu -> Help -> Edit Custom VM Options...
添加一行-Xmx8192m ，保存重启 WS 。8192 是可分配最大内存，看项目给。

用的二手 dell wd19tb 还行

都是推广，卡是真的，价格看仔细。大部分是高价套餐+限时返利=低价大流量