@lentrody 并不是，PVP 本身就容易造成阳痿，只是 PVP 阳痿一般就是不玩了，而不是到处发帖说我电子阳痿了

我只说我自己遇到过的，各地情况不同不能一概而论，我在南方：

移动是我用过的最吝啬的 ISP ，别看它的宽带似乎更便宜。它的宽带问题最多，众所周知的“墙中墙”就不说了，高峰期（晚上 7 点-10 点），它的上传丢包相当严重。
跨运营商里，哪怕同城，如果有一头是移动，不管它是作为下载，还是作为上传，都会限流，流量大了就丢包。推测和运营商网见流量结算有关。在这一点上，联通 + 电信都要好很多。

电信和联通虽然好于移动，但是在连续大流量上传后，也会触发类似 QOS 那样的丢包机制，这个现象从去年开始变的严重，推测是 PCDN 的余波问题。

我和楼主一样也是远程桌面，串流的爱好者，但是我个人的看法是，经济衰退，ISP 变的更在意网间流量的费用，再叠加 PCDN ，使得 ISP 现在无比关注民用宽带的上传流量。当然，人家表面是绝对不会承认限了你的流的。实际上民用宽带的上传带宽都是虚的，因为它实际给不了（上传流量在跨运营商，跨地域的时候，流量是单独算价格的）。这个矛盾解决不了之前，远程桌面勉强用用，串流就别多想了。偶尔用用可以，流量超了就被限，跑不掉的

web 这种高度动态的玩意，天生就不适合这种需要长时间静态编译检查的语言。你看在 web 领域能占据一席之地的语言，要不就是那种“瞎写也出不了大问题”的脚本语言，要么就是“虽然我要求严格但是我编译很快”的静态语言。rust 这种改起来之前，得认真想清楚，以通过编译器的语言，确实不是回合

@drymonfidelia
既然是两根内存条，有没有试过拔掉一根，再试试会不会蓝屏，如果不会，那就是这两条不能一起用，有兼容问题，我曾经遇到过。

CPU 缩肛可能不是这个表现，CPU 缩肛的典型表现是首次运行游戏，编译着色器的时候会失败。

不要过于相信稳定性测试，不一定有用的，我当初也是内存蓝屏问题，但是稳定性测试就是跑不出来。

现在就觉得花钱买罪受算好的了，等你结婚后再过个几年，你搞不好就会问自己当初是不是傻了，为啥要结婚了

你先想清楚一个问题，混动算油车还是算电车。

传统油车铅蓄电池非常的小，才导致无法智能化，那么解决方案很自然的就想到了加电池，但是简单的加电池又会增重。所以油车如果沿着这个方向演进下去，一定会变成混动。

再怎么折腾也米用，这一波 AI 是在消灭工作，而不是增加工作，理解这一点就明白，你越卷工作越少

@SmithJohn 教师可是人与人交流强相关领域，AI 目前真干不了这个，千万别以为教师的任务只是教课

据说音响行业 10 年左右才会有一次比较大的技术革新

你为什么不分手呢？
两性交往应该以自己舒服不舒服为标准，自己已经不舒服了，还来论坛抱怨？

墙是双向的。
你要看优酷听网易，基本都是因为 IP 限制，而这些都是限制都是基于 ip 必须是大陆的。
据我所知，大陆的阿里云和腾讯服务器，照样会被墙影响，所以你的问题是你能不能连回来，连不回来，那这就没戏。


@totoro625
这方案，首先第一个问题，国内主机连海外 VPS 怎么会不受到墙影响？
甚至流量稍微大点就会被注意到。
其次，国内连海外 vps 的速度怎么保证，出口带宽就那么多啊。

前端很难，对于后端出身的人来说，CSS 简直是魔法一样的东西。

但是前端又不那么难，因为绝大部分人在平时开发中遇到的前端需求是不会特别难的，而且最重要的是，前端的几乎任何单独页面的复杂度都是有极限的，而且这个极限的天花板并不高，这也是为啥几年前前端同学有句自嘲叫“前端没有大项目”的由来。

基于这两点，如果你不想花大钱，那你还是要稍微学习一下 html + css ，你作为后端可能觉得很难入手，但是我们现在有了 AI ，你甚至可以把一个 CSS 文件丢给 AI ，让 AI 解析一下这玩意干了什么，实在不行。你可以尝试从头，在 AI 的指导下写一个新的 CSS 文件，达到旧 CSS 文件的效果，不要觉得这不可能，其实很多前端同学，在拿到一个二开项目，遇到排版问题搞不定的时候，最常见的选择就是“老子重新写一个”，还记得我上面说的没，单个 web 页面的复杂度天花板并不高。一旦你从一个页面的源头搞定了这个页面的样式问题，再改新的你就不会觉得多难了。

在前面的基础上，如果还是遇到了难度极高的排版问题，再去网上花点钱找人解决，前端的开发者现在比后端还要多，并不难找到人。

@june4
举例如下：

以 width 对 margin-left 的影响为例，假设有两个 div ，parent 和 child ，child 在 parent 里面，.parent 里面的 .child 宽度为 300px ，现在我给 child 添加一个 margin-left: -10px ，会发现整个 .child 左移 10 像素。好的，于是我们知道 margin-left: -10px 会让元素整体左移。

真的是这样吗？

这个时候把.child 的 width 去掉重新做实验。

就会发现 margin-left: -10px 并没有让整个元素左移，只是让左边缘左移了，右边缘并没有动。现在来总结一下：如果指定了 width ，那么 margin-left: 10px 会使元素整体左移如果没有指定 width ，那么 margin-left: 10px 只会使做边缘左移（也就是宽度扩大）

这就是非常典型的不正交：
* 为什么 width 的存在与否会影响 margin-left 的作用？
* 有没有 width 之外的其他属性也会影响 margin-left 的作用？还有哪些我不知道的会互相干涉的属性？

这就是不正交的恐怖之处，你只有把所有属性与 margin-left 一起用一下，才能得知 margin-left 的真正规律。

这还只是两个属性，如果更多的属性一起过来呢？

这些“不正交”的例子，需要一个个去记忆，各属性被影响的情况都不一样。
所以一直就有人说 CSS 不是编程，是“背表”，源头就在这。

现代基于 CSS 的 UI 已经很大程度把这些东西给屏蔽了，大部分时候，写 UI 只是在排列组合一个个的方盒子，确实比当初手写 CSS 容易很多。

但是这个“不正交”问题并没有被彻底埋葬，它就在那里，说不准啥时候就蹦出来。

其它的，类似 html + CSS 这样的“标记语言 UI 设计系统”，在样式问题上，基本都没有采取 CSS 这样的设计

@june4
最大的问题在于 CSS 自己的设计思路，它不是个“正交系统”。所谓正交系统，你改变 A 条件，它应该只产生 A 结果；但 CSS 不是这样，CSS 改变 A 条件，会引发 B 条件联动改变，从而影响出 B 结果。

这是 CSS 让很多人觉得难以掌握的根本原因。CSS 最初的设计者是为了让这个东西更符合设计者直觉，而编程人员的直觉则更强调逻辑直觉。所以长久以来，编程界就有相当一部分人觉得 CSS 难以学习，而另外相当的一部分人觉得 CSS 有什么难的？就是因为这种思维模式的阻尼。

后来 CSS 确实加了一些专门为 UI 设计的布局，比如你说的 flex/grid, 但是 CSS 本身不正交这个问题，一直拖累 CSS 的 UI 编程。
如果你观察过其它的，“类标记语言 UI 设计系统”，诸如 WPF ，它们确实搞的很像 Html + CSS ，但是它们都极度的让自己的系统正交，避免出现 CSS 这种“明明改的是 A 怎么 B 跟着跑？”这类问题。

样式表描述界面是个很好的想法，完全可以用于 UI ，但是 CSS 本身的不正交设计，让这东西用于 UI ，在编程开发者看来痛苦万分，所以才出现了如此多的诸如 bootstrap 这样试图屏蔽 CSS 不正交问题的方案。

@june4
我认为那位朋友没说错，HTML / CSS / JS 就是不适合写 UI 。而且理由人家也说的很清楚了，UI 应该以组件为单位，但是现实里我们写一个 UI 组件却需要再三种语言里切换（而且是三种思路完全不同的语言），这会带来巨大的心智负担。

最早说 Web 这套逻辑适合开发 UI 的，是因为 UI 界有个观点，认为“标记型语言”是最适合描述 UI 的，而 Html 刚好是标记型语言。所以 UI 界才开始注意到 web 这个东西的 UI 潜力。但是偏偏 CSS 这个东西，它不是为 UI 设计的，它是为排版设计的，排版的需求和 UI 的需求，只能说有交集，不能说完全匹配，所以你如果用 CSS 去做 UI 的话，总会被 CSS 里为排版设计但不是为了 UI 设计的那部分特性干扰。很多人对 CSS 的畏惧就来自于此，这东西并不是为 UI 开发的。

相比而言，性能反而不是最重要的问题，毕竟不是所有领域的 UI 都对性能有较高要求。

HTML / CSS / JS 这套，从 2000 年左右开始，一直到现在，不断变革，不断翻来覆去大家吵架，已经 20 年了，大家还是没争吵出个最佳实践来。而争吵的业务在什么领域呢？就是 UI 。单纯的没有交互的排版页面大家反而没争议。这恰恰说明了，这套东西基础层面上有问题，以至于大家反复的在实践上翻烧饼。这个问题，其实就是基于排版设计的系统，和基于 UI 设计的系统之间的阻尼。

jellyfin 装在 NAS 服务器上有一个重要作用是将视频转码，降低码率后再播放的，楼主你直接从 NAS 上取原版的视频，需要很高的上行带宽，不是所有人的家庭网络都有你那么好的条件的