怎么感觉是 rdp 的端口没开啊，你内网试试 rdp 主机的端口是好的吗？然后再看看外网连 rdp 端口是不是有防火墙

笔记本有功耗墙和温度墙，台式机和服务器可以认为没有。
性能和功率直接挂钩，游戏本的大板砖也才 300w-500w ，台式机 1000w 轻轻松松，服务器就更别说了。
所以笔记本是没法去和台式机比性能的

@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 不正交问题的方案。