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

@bler 你理解错了，操作系统没有编码一说。字符串对操作系统来说是透明的字节序列。操作系统并不关心字节序列到底是什么编码方案，关心编码模式的是应用程序（ Application)，应用程序自己必须要知道你使用的字符串到底使用的什么编码，否则就无法解析。各个编程语言内置的 string 类型使用的编码都可以是不同的。例如 Python 用的 utf-8, c#/javascript 用的 UTF16 。因此这个属于应用程序需要关心了。例如你是要 C#将一个文件是要 UTF-16 写入文件，在 python 中是要 utf8 去加载这个文件，就会乱码，这个时候 python 加载这个文件必须显示告诉加载方法应该文件是要的是 UTF16 编码，这个时候 python 会将文件是要 utf-16 加载后转码为 utf-8, 从而才能在 python 中正常的处理这个字符串。

1. Unicode 字符集： 每个字符对应的码点不会变化（只会添加新的 Code)
2. UTF-8/16/32: 是存储方案（编码方案），也不会变化，只会添加对新的 Unicode 字符集版本的支持。
3. 压缩软件没有办法知道用的什么格式，要不再元数据携带，要不最终用户告诉它使用的什么编码，要不靠猜测，要不靠诱探。

PS: 各个编码方案通过编码表是可以相互转换的，但是很多转换是不可行的，例如 ASCII 的字符集就很小，没法包容 UTF-8 的所有有效字符集。

配速 5 到 6, 控制步频，长期跑让后降心率，一次性跑 10-15km ，不要急着提升配速。至少能在心率稳定跑完半马再考虑提升配速的问题。

@haython 你要的是可信环境，而目前除了专门的硬件，手机这种东西，包括微信的客户端都不是可信环境，因此要做到你想要的功能是不现实的。只能提高破解者的门槛，如果利益足够，最终肯定还是防不住的，过度加强会导致成本上升，正常用户体验也会受限。电脑上播放的 DRM 加密视频就是一个典型的例子。

Jwt 主要用来给资源授权的，生命周期很短。几乎不做权限回收控制。如果想要做有状态的会话凭证，又不想维护服务器状态，理论上就是矛盾的。

@codehz 我觉得为了限制这种滥用， 应该将除了 CPU 以外的所有计算机资源都视为受限的，不允许这些辣鸡 APP 随意调用，强奸用户，硬件拥有者应该能够禁止 APP 对任何硬件的访问权限。至少需要给用户一个兜底选择，例如从操作系统层面，直接禁止任何 APP 调用摄像头，麦克风，扬声器。

@kumoilain 我感觉我需要的是彻底禁止一个 APP 使用使用扬声器。或者针对当个软件的音频条件功能。感觉扬声器也应该和摄像头一样，使用需要申请权限。