你服务器返回 403 ，也能怪到 ueditor 上？这是什么奇葩理论？虽然百度口碑一般，也别乱喷。

@jwdstefanie 数据完整性、安全性等不要依赖前端，必须后端解决。

--- 区块链是一个类似于链表的数据结构，该数据结构中每一个节点记录了前节点中数据的 Hash 值、当前节点的数据。
在当前节点不变的情况下，前节点的任何改变都会使得这条链无效(invalid)。

浏览器的历史记录就是按照这个定义来执行的。。。

http status 始终返回 200 ， data.code 用于表达你想要的 status ，比如 data.code = 404, data.code = 401.
挺好，没觉得不适。
http status 应该表示服务的状态，而非数据的状态。
只要服务正常，返回 200 不是应该的吗？

@wxx199101046 上次 pm2 用法错了，开双核后转发效率有提高了

@Arrowing 服务器 24 核，性能不要太好。想问下，你用的测试软件是什么？

@zhuangzhuang1988 了解了一下， VS Code 有 mac 版本

@sampeng 是这样的，发起 1000 个请求，并发为 1 ，每次耗时都很低，但一旦并发数加大，加到 10 ， 50 ， 100 ，耗时就随之增加，可以认为是并发下的问题。

@zhuangzhuang1988 基于 Visual Studio ？ osx 系统比较尴尬。。。我安装个虚拟机吧

@sampeng 反向代理不是根本目的， node 做页面渲染的，转发接口这是其中一部分，不是 ningx 干的事儿。

@wxx199101046 用 pm2 简单部署了下，结果还是一样

@xxxyyy 用了你的代码，用时变的比较均匀，截取最长耗时的和最短耗时，如下：

```
# 最短耗时：
127: 235ms
34: 285ms
62: 283ms
72: 283ms
97: 283ms
55: 289ms
89: 286ms
124: 283ms

# 最长耗时：
279: 611ms
267: 612ms
437: 600ms
467: 599ms
421: 608ms
417: 609ms
436: 608ms
479: 606ms
461: 607ms
443: 608ms
448: 607ms
438: 609ms
430: 609ms
```

@Arrowing 没有实用多核多进程

@sherlocktheplant 简单代码已附言

@xxxyyy 我从 v6.9.1 升级到了 v7.0.0 ，耗时减少一半，但依然有超过 1000ms 的。 api 地址干脆使用了 http://localhost ，是本机 nginx 默认页面，耗时从 150ms ~ 500ms 左右都有。

@ibigbug
@sherlocktheplant 我都是在本地测试，只有后端接口是局域网内一个服务器， mac pro 13 中配，应该不是你们所说的问题

@xxxyyy 直接压后端耗时也很小的，所以是前端请求问题。
ab 压前端转发：
Requests per second: 171.05 [#/sec] (mean)
Time per request: 1169.261 [ms] (mean)
Time per request: 5.846 [ms] (mean, across all concurrent requests)
Transfer rate: 1981.31 [Kbytes/sec] received

ab 直接压后端接口：
Requests per second: 858.12 [#/sec] (mean)
Time per request: 233.068 [ms] (mean)
Time per request: 1.165 [ms] (mean, across all concurrent requests)
Transfer rate: 190.23 [Kbytes/sec] received

@mcfog 你理解反了， 8080 上是 node sever, 9190 是后端接口，并发 node 上一个地址，该地址又用了 request 去请求接口，统计了一下 request 开始到完成的耗时。 然后你说的 request 连接池是 'pool': { maxSockets: 5000 } ？改为 5000 也没有明显提升。

@janxin 没有做任何进程操作，默认的简单程序