这个和 JS 没有一毛钱关系，你要怪只能怪 ECMA 规范和 IEEE64 浮点数规范，还有 JSON 规范。

没有办法知道，python 的依赖管理就是一坨狗屎。

没什么问题。

你的理解没什么，基于文档的数据库的确更加适合 DDD ，但是随之而来的问题是事务一致性。

Golang? 你确认没问错? 线程 or 进程？

@jackielllv7158 改 host 或者使用公司内部的私有 DNS ，你总的选择一个，或者干脆反编译。

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

被墙很久很久很久了。

正确的，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 主要是这种问题，我感觉的确有灌水的嫌疑。