直接下载到本地，或者使用本地代理服务器缓存资源。

被墙很久很久很久了。

正确的，mac 下的滚动卡顿，特别是鼠标，我都需要好使用第三方工具。

每次使用 C++我都感觉自己在被编程语言使用，而不是我在使用编程语言，对这个什么乱步八糟模式都支持的语言实在没有任何好感。不同人/不同团队写出来的代码有时候完全是不同的风格，如果你喜欢 All in One 那就直接上 C++也行。如果你喜欢自己彻底掌握一个工具后再使用它，建议尽早离开，这个语言实在太难掌握透彻了。如果只是使用 C-with Class 的 C++那会好一点。

先学 C 语言，然后直接去学习 Rust/Golang ，抛弃 C++.

@Lounode 没看出有什么问题，我写了 10 年 C#,2 ，3 年 Java ，感觉没啥问题。

@dnjat 如果对你来说，HTTP 协议只是一个传输协议，就像 GRPC 使用 HTTP2 一样，那么这种风格对你来说没什么用处。RESTful API 是个很复杂的东西，它涉及到了最初 HTTP 协议的思想和 WWW 最初诞生的一切都是超链接的理想状态。URI 的设计其实是个复杂的话题，远非很多人想的那么简单。RESTful API 是 HTTP 协议最初的设计者希望人们使用 HTTP 的方式。理想很丰满，显示很骨感，大家都抛弃了 HTTP 本身的很多特性，决定 POST 一把梭，甚至没几个完整看过 MDN 的 HTTP 协议的介绍。如果要想要搞清楚这个问题，需要先研究 HTTP 协议（ MDN 的内容就已经够了），如果还想深入理解，最好去看 RESTful API 作者的博士论文。
另外如果你的程序并不是面向资源，而是本质上就是一个 RPC 模式，前端就是一个 Application,目的就是要发送执行命令调用，用谓词结构的确是最节约时间的。
如果你的 API 有很多消费者，是面向大众的，有很多客户需要消费你的 API, 那无论是否使用 RESTful API ，你都要好好考虑怎么设计一个文档的 API URI.

楼上一群说 RESTful API 缺陷的，你们到底理不理解这个东西究竟是什么，解决的问题是什么。先学会正确使用这个东西才来谈它的缺陷。
如果你的 API 是面向浏览器而且是自包含的，我仍然建议你上 RESTful API 。如果你们的团队完全不理解基于资源的 URI Schema 设计. 那就选择 RPC 吧，比较这个玩意不需要动脑子。

很多网站的设计目的就是不允许你跨区域访问，根据 IP 来限制用户，这是网站后端服务器的功能设计要求。

@docx 确保每个人看到是需要成本的（站点需要重新开发此功能），而且站长需要花很多精力来确定到底是不是第一次发这个，说到底这只是一个个人站点，一切的喜欢都是站长个人说了算。任何规则一旦复杂化了，执行成本就会变得高。站长的确应该调整一下策略，例如禁言一段时间，并说明禁言原因。这样只需要在通知系统添加一个规则。其实这种个人交流讨论的站点，的确应该尽量避免 AI 灌水，否则很容易变成垃圾堆。也许是因为这种 AI 内容触动了站长的根本利益，所以采取了最激烈的手段，杀一儆百。

没有办法，很多网站会有其它手段，强制按照浏览器的各种综合信息+IP 一起确定你的语言，不接受用户手动设置的 Accept-Language ，也有很多网站的多语言就是用 Accept-Language 实现的(js 发起的请求，通过用户选择的语言，来发起请求，从而请求对应语言的资源）。各个国家的法律一一样，服务器后台会根据的区域和语言下菜。

@docx 主要是这种问题，我感觉的确有灌水的嫌疑。

@aabbcc112233 站长已经多次明确强调，不允许发布 AI 生成内容，而且也不是第一次说明了。

你的 SaaS 设计的时候没有考虑私有化部署吗？我们的都是允许私有化部署的，只要客户提供私有化部署的全部资源，这样部署完毕后，整个软件就和我们一点关系也没有。运维也要他们自己负责，一般也无法及时升级。

@bler 但这种粗暴的解决方案有时候也存在问题。因为某些系统，甚至不携带非 ASCII 的码表，也无法显示非 ASCII 编码的字符，这就是另外一个话题了，这些都是历史遗留问题。

@bler 压缩软件会在内部使用一个固定的 encoding 模式获取到的密码的 byte[]表示，这个表示在 Encoding 指定值不变的情况下是不会有什么变化的。
另外就是 zip 这种压缩编码存在缺陷，的确会又解析错误。例如你在 GB2312 chcp 下压缩一个文件夹，然后在 UTF8 chcp 的另外一个计算机上解码，文件夹就会乱码。因为 zip 这个格式规范并没有存储压缩时候的文件名的字符串编码格式，导致它总是按照操作系统当前的编码来处理字节序列，这回导致文件名这种东西，使用 gb2312 byte 字节存储，却使用 UTF-8 解码，这个时候你就会看到解码后的文件名称错误。这个纯粹是因为 zip 这种文件格式存在缺陷。这种情况你就只能显示的告诉解压软件不要使用操作系统默认编码来解压文件，而是使用你手动指定的编码格式。
软件应该避免依赖操作系统的默认编码格式。否则你的软件很可能无法正常在各个不同国家的系统上运行。

@bler 另外存在一个叫做码表或者 Encoding 的东西，它可以将不同 Encoding 编码的字节序列做相互转换，例如将一个 byte[] /utf-8 转换为 byte[] utf-16, 字符串内部都使用 byte[]序列表示。获取到一个字节序列后，如果你不知道它究竟是什么编码方案，甚至不知道它不是字符序列，就只能靠探测了。例如 VSCode 默认就会一个探测功能，可以猜测一个文件使用了什么 Encodeing 模式，但是这个探测并不是总是靠谱。

@bler 另外就是，操作系统本身是由内核+驱动+一堆周边软件构成的。操作系统内核部分的确也有自己的字符串编码模式，但这个和你普通的应用程序没关系，你们也不同共享内存，除非涉及到内核调用和封送。这个时候你就需要关心操作系统内部字符串的格式了。或者你调用一些系统组件，这个时候返回给你的字节序列你必须按照操作系统的编码模式转换为你本地编程语言的字符串使用的编码格式，不知道我这样解释，你理解没有。