ESXI 不支持核显（如果有成功案例求教程）
E3C236D4M-4L 板子略显奇葩，但没问题
ZFS 请备好足量的内存
需要图形界面请自备 A 卡，并做好折腾的准备

最后提示： All in one 对于喜欢折腾的人来说不是一个好选择

@noli
总觉得我们俩不在一个频道上，这话题就此终止吧。

@noli
1 、只要 200 就意味着 API 可访问， 200 以外数值一律当成异常处理（例如程序错误会抛个 500 ）
2 、缓存可依据 HTTP 头信息判断，不仅仅是状态码
3|4 、重看一遍我的回复， 200+json 我认为很适合于 Web API ，啥时候我说不看场景强制用这种模式了？

@noli
1 、 API 监控报警只监控 200 以外的状态码即可判断 API 失效
2 、 API 的缓存从不应只依赖返回码
3 、 JSON 是一个很通用的实现，除嵌入式以外，暂时没想到哪个领域不具有解析 JSON 的能力。
（别忘了我坚持 200+JSON 的领域是 Web ，本来 Web 这种业务多变的地方就应该独立做一套 API ）
4 、一个非 200 响应的 API 给浏览器统一成 200 响应再送回去你确定这样做合适？

@noli 请教缺点多于优点的缺点是啥

@noli
我觉得已经没必要讨论下去了。
你这么说法完全就是为了反对而反对了。

@noli
理性点看待问题，话不要说绝。
在 Web 场景下保持 200+JSON 响应消息这么设计是很合理的选择。
不要为了反对而反对，除非你能给出更优解。

套用知乎句式 “抛开场景谈设计就是耍流氓”

@noli
其实我想说的情况是公司内部自签发证书在网关拦截请求进行监控的情况下 HTTPS 是不可靠的。

考虑到运维以及可能出现的各种网络问题引起的状态码异常（客户端劫持）
我是认为 Web 环境中不适宜用 HTTP 状态码来代表业务状态，软件的 API 倒是可以用这种形式来实现。
但是为了明确区分应用层故障还是网络异常， HTTP 状态码保持 200 在某些时候是更合适的选择。

@noli HTTPS 也可以劫持，别忽略例外情况

@noli
当你遇上一个没法更改的机房设备的时候你就不会这么说了。。
HTTP 状态码来表示资源状态那当然是很好的做法
但是当网络路径中存在一些奇葩的设备带有奇葩规则的时候这就不是一个合适的选择了

这也是我在上文中强调“外网”的原因。

看上去像是 多路接入+策略路由+分销 N 次的城中村宽带

@noli
考虑到项目的规模才应该使用更通用的实现，即便这个实现在某些时候看上去并不“优雅”
为了“优雅”而对问题视而不见，这不是一个合格的工程师应有的态度

@shadownet DELL 这种情况是休眠被启动了吧？因为震动导致那个开关被触发了之类的。。。

@noli 要考虑到网络上各种奇葩的中间设备会有的奇葩规则，开发时还是要看 API 用在哪个地方
如果是内网，不经过啥奇葩的中间设备的话， HTTP 状态码直接表示资源状态也是可以的。
但是在外网，考虑到各种奇葩的中间设备有可能存在的情况下， 200 是个更稳妥的选择。