api?{"req1param":{},"re2param":{}}
或考虑伪静态之类 api/{"req1param":{},"re2param":{}}

参数也可以编码一下

现在还有个 GraphQL 的新概念，需要后端配合修改据说可以多个 api 整合但是会增加不少工作量没用过

直接拼接倒 url 或者 (如果有冲突)装入 json 整个作为一个参数?
反正作为 get 来说参数应该不多，如果参数太多还用 get ，感觉是有问题的

@NeezerGu 单机的话 redis 主要瓶颈在内存，多开不能提高什么性能(我怀疑还会降低)
如果是多机，那不如直接 redis 集群了，还不用考虑分配系统逻辑更简单

@avastms 进入单页面时代之后，前端内存照样很容易泄露如果不注意资源释放，举个例子，通过组件创建 video 标签播放视频，退出时哪怕你把 video 移除可能都没有真正释放，必须先 stop
不释放的后果就是内存不断占用知道耗尽资源
另一个类似例子，单个标签下可创建的多媒体标签是有限的，哪怕 remove 掉似乎也会占用额度，超额之后就无法再申请

确实不实用，自己私下想的算法安全性测试都没有没人敢用(而且这图看起来似乎。。。安全性不太高的样子)，还不如楼上说的直接 aes 跑一遍，安全性经过权威测试，速度芯片级优化，体积也不会增大

页面太乱了，而且页面滚动影响了滚轮滑动

原来是我的帖子。。
你这是，自己说错话被揭露找不到理由反驳了，想回来找 v 友安慰么？

我赞成放 body ，发现国外有些大平台都把错误码体现在 http 感觉有点不可思议，网关错误跟程序错误傻傻分不清

佛性点看待，go 的 err 确实有点不那么令人舒服
不过看过了 python 和 shell 的语法，又觉得 go 还是挺可爱的

路人强进
有 nas+百度云，没考虑过体积问题 🤦‍♀️
直接全量加密丢 nas 然后同步百度云的，顺便说下目前地球上似乎没有性价比比百度云高的产品

@yin1999 当然不一样，哪怕是垃圾加密，有加密安全程度还是高得多

花 10 分钟换个证书
or
换回 http 自己实现非对称加密传输

严格来说没有正确答案，无论数据量大小多少，取决于你的数据结构，索引、磁盘、网络等情况，都可能出现不一致的结果。
例如：按楼上朋友的看法反例，数据量少可能 java 快，但实际生产中本来很快的查询因为 join 一个不合理的数据集导致速度骤降的现象并不少见(即使结果数据不大)，这种情况把数据分别读出来处理反而更快

但设计合理的情况下，又可能 join 更快

所以没有标准答案

这样才够规范，强类型语言确实会预定义很多类型，写的时候感觉麻烦点但是可读性可维护性都优于 php python 的万能结构，我也是写 php 转的，不过之前也写过 c Java ，在编译语言中对比起来感觉 go 真的足够简洁了，你应该转变下自己的思维，不能想同时要 go 的强大和 php 的灵活
另外你说的近乎一样的机构体不清楚你是怎么规划的，如果遇到接近的我一般倾向于复用，最好能展示下示例代码

@vision1900 你说的只能算非常熟练的工程师不能算非常好，因为真正的工程师已经脱离“端”这个概念了，参考法布里斯•贝拉，从硬件到芯片到前端，样样都是顶级水平🤣

但是判断 root 不需要 root 权限吧，支付宝和很多银行 app 都有判断
当然也可能负责这个判断逻辑的小伙思路清奇

每天的并发量是 300w 左右。。。
发帖人可能对目前的硬件性能有什么误解，一天才这么点峰值给你算高点 1 万 qps 够用了，只要硬件不太差轻轻松松就扛下了，完全不需要丢内存
甚至自己写个文本数据库都能 hold
而且你的峰值很低完全不用担心数据库太占资源的问题，建议用 m2 硬盘+rocksdb ，qps 轻轻松松上 10 万+而且对其他服务影响不大

按这个思维，只有躺平才不是 m ，因为任何努力都会虐待自己