找到 ExceptionHandler，去哪里改 render 函数，加上 header

@jswh 补充一下，如果还在用 php5.*建议尽快升级到 7.*

看错了，对 linux 的不了解，实际是这样的
物理内存：共 3.702 G , 已用 3.082 G , 空闲 0.62 G , 使用率 83.25%

Cache 化内存为 2.058 G , 使用率 55.59 % | Buffers 缓冲为 0.15 G

真实内存使用 0.874 G , 真实内存空闲 2.828 G , 使用率 23.6 %
============================
另外你 2 核心 4G 服务器，这个 php-fpm 设置得有点高了，可以稍微小一点，毕竟 mysql 也是内存大户。


Linux 要看实际使用内存，不要把 buffer/cache 算上。和 Windows 策略不一样

如果又要低功耗又要高性能，其实有一个 e3 1220l v2。就是性价比不高，e3 1220l 功耗稍微高一点但是便宜不少。然后找个 itx 板子和 itx 的机箱合计也不会很贵，当然这个是捡垃圾的玩法。
不在意功耗的化 itx 能用的就太多了，各种小主机准系统也都可以。

另外我我再个楼主一个思路，去淘宝收一个以前的国产 atom 寨板，拆了之后把主板拿出来单独用，不要问我怎么知道的，我的酷比魔方 i7 手写板，就是这么被我拆了的。树莓派的大小，比树莓派好不少的性能，不关心外设驱动 linux 随便装。

通常晚上休息感觉更好的人都是夜猫子，比如我

你的理解是实现层面的。建议看看微服务的发展历史，然后尝试回答为什么要这样。

总之这完全不是能不能的问题，完全就是个设计风格和品味的事情。但唯一确定的是，单一项目内部这个风格和品味需要统一。

@jswh 另外，完全不区分 get/post，在一些七层路由服务里可能会有问题，比如客户端的 get 请求里面带了 body，但是一般 get 请求没有 body，七层路由转发的时候就不处理了。而且 get 的参数长度限制不一，所以 RPC 类型的 API 还是用 post 比较多。

@jswh 上面的举个例子，LDAP 完全是自己的一套协议，但是也可以走 http 实现。

RPC 类型的 API，有时候确实不分 get/post，有时候只能 post，有时候甚至支持 get/post 混用，有时候只能 websocket。完全看设计接口框架的人的看法。有的 RPC 觉得反正你把参数给我就行了，我不管那么多，我不关系 http 规范，只把 http 当作一种数据传输协议用。
只有 RESTful 类型的 API，才一定会强调说 get/post，因为它要依赖 http 动词来判断动作。

我以为是 45 瓦的 itx 小钢炮，对不我走错门了。

要住院观察的

单纯从业务上考虑。如果业务之间的归属一个 transaction 里面的，用 rpc。如果业务之间不是同一个 transaction 只不过是流水线关系的数据传递，用队列。

@Aresxue 你也说了不考虑扩展嘛，这个就是个权衡的事情。

不推荐的意思是这样做虽然不一定是最优的，但大概率可以避免一些前人犯过的错误。如果非常确定这样做没有问题，甚至更好，又有何不可。

第一次在 v2 看到招 rust

另外，插个话，还有谁记得以前得佛曰